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Chapter 1 

Introduction 

1.1 Abstraction 1 

1.1.1 Introduction 

Abstraction is the process of hiding the details and exposing only the essential features of a particular concept 
or object. Computer scientists use abstraction to understand and solve problems and communicate their 
solutions with the computer in some particular computer language. We illustrate this process by way of 
trying to solve the following problem using a computer language called Java. 

Problem: Given a rectangle 4.5 ft wide and 7.2 ft high, compute its area. 

We know the area of a rectangle is its width times its height. So all we have to do to solve the above 
problem is to multiply 4.5 by 7.2 and get the the answer. The question is how to express the above solution 
in Java, so that the computer can perform the computation. 

1.1.2 Data Abstraction 

The product of 4.5 by 7.2 is expressed in Java as: 4.5 * 7.2. In this expression, the symbol * represents 
the multiplication operation. 4.5 and 7.2 are called number literals. Using DrJava, we can type in the 
expresssion 4.5 * 7.2 directly in the interactions window and see the answer. 

Now suppose we change the problem to compute the area of a rectangle of width 3.6 and height 9.3. Has 
the original problem really change at all? To put it in another way, has the essence of the original problem 
changed? After all, the formula for computing the answer is still the same. All we have to do is to enter 3.6 
* 9.3. What is it that has not change (the invariant)? And what is it that has changed (the variant)? 

1.1.2.1 Type Abstraction 

The problem has not changed in that it still deals with the same geometric shape, a rectangle, described in 
terms of the same dimensions, its width and height. What vary are simply the values of the width and the 
height. The formula to compute the area of a rectangle given its width and height does not change: 

width * height 

It does not care what the actual specific values of width and height are. What it cares about is that the 
values of width and height must be such that the multiplication operation makes sense. How do we express 
the above invariants in Java? 

We just want to think of the width and height of a given rectangle as elements of the set of real numbers. 
In computing, we group values with common characteristics into a set and called it a type. In Java, the 
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2 CHAPTER 1. INTRODUCTION 

type double is the set of real numbers that are implemented inside the computer in some specific way. The 
details of this internal representation is immaterial for our purpose and thus can be ignored. In addition 
to the type double, Java provides many more pre-built types such as int to represent the set of integers 
and char to represent the set of characters. We will examine and use them as their need arises in future 
examples. As to our problem, we only need to restrict ourselves to the type double. 
We can define the width and the height of a rectangle as double in Java as follows. 

double width; 
double height; 

The above two statements are called variable definitions where width and height are said to be variable 
names. In Java, a variable represents a memory location inside the computer. We define a variable by 
first declare its type, then follow the type by the name of the variable, and terminate the definition with a 
semi-colon. This a Java syntax rule. Violating a syntax rule constitutes an error. When we define a variable 
in this manner, its associated memory content is initialized to a default value specified by the Java language. 
For variables of type double, the default value is 0. 

NOTE: Use the interactions paneof DrJava to evaluate width and height and verify that their values 
are set to 0. 

Once we have defined the width and height variables, we can solve our problem by writing the expression 
that computes the area of the associated rectangle in terms of width and height as follows. 

width * height 

Observe that the two variable definitions together with the expression to compute the area presented in 
the above directly translate the description of the problem -two real numbers representing the width and the 
height of a rectangle- and the high-level thinking of what the solution of the problem should be -area is the 
width times the height. We have just expressed the invariants of the problem and its solution. Now, how do 
we vary width and height in Java? We use what is called the assignment operation. To assign the value 
4.5 to the variable width and the value 7.2 to the variable height, we write the following Java assignment 
statements. 

width =4.5; 
height =7.2; 

The syntax rule for the assignment statement in Java is: first write the name of the variable, then follow 
it by the equal sign, then follow the equal sign by a Java expression, and terminate it with a semi-colon. 
The semantic (i.e. meaning) of such an assignment is: evaluate the expression on the right hand side of the 
equal sign and assign the resulting value into the memory location represented by the variable name on the 
left hand side of the equal side. It is an error if the type of the expression on the right hand side is not a 
subset of the type of the variable on the left hand side. 

Now if we evaluate width * height again (using the Interactions Window of DrJava), we should get 
the desired answer. Life is good so far, though there is a little bit of inconvenience here: we have to type 
the expression width * height each time we are asked to compute the area of a rectangle with a given width 
and a given height. This may be OK for such a simple formula, but what if the formula is something much 
more complex, like computing the length of the diagonal of a rectangle? Re-typing the formula each time is 
quite an error-prone process. Is there a way to have the computer memorize the formula and perform the 
computation behind the scene so that we do not have to memorize it and rewrite it ourselves? The answer 
is yes, and it takes a little bit more work to achieve this goal in Java. 

What we would like to do is to build the equivalent of a black box that takes in as inputs two real numbers 
(recall type double) with a button. When we put in two numbers and depress the button, "magically" the 
black box will compute the product of the two input numbers and spit out the result, which we will interpret 



as the area of a rectangle whose width and height are given by the two input numbers. This black box is in 
essence a specialized calculator that can only compute one thing: the area of a rectangle given a width and 
a height. To build this box in Java, we use a construct called a class, which looks like the following. 

class AreaCalc { 

double rectangle (double width, double height) { 
return width * height ; 

} 
} 

What this Java code means is something like: AreaCalc is a blue print of a specialized computing machine 
that is capable of accepting two input doubles , one labeled width and the other labeled height, computing 
their product and returning the result. This computation is given a name: rectangle. In Java parlance, it 
is called a method for the class AreaCalc. 

Here is an example of how we use AreaCalc to compute area of a rectanglee of width 4.5 and height 7.2. 
In the Interactions pane of DrJava, enter the following lines of code. 

AreaCalc calc = new AreaCalc (); 
calc. rectangle (4. 5, 7.2) 

The first line of code defines calc as a variable of type AreaCalc and assign to it an instance of the class 
AreaCalc. new is a keyword in Java. It is an example of what is called a class operator. It operates on a 
class and creates an instance (also called object) of the given class. The second line of code is a call to the 
object calc to perform the rectangle task where width is assigned the value 4.5 and height is assigned 
the value 7.2. To get the area of a 5.6 by 8.4 rectangle, we simply use the same calculator calc again: 

calc . rectangle (5.6, 8.4); 

So instead of solving just one proble -given a rectangle 4.5 ft wide and 7.2 ft high, compute its area- we 
havebuilt a "machine" that can compute the area of any given rectangle. But what about computing the 
area of a right triangle with height 5 and base 4? We cannot simply use this calculator. We need another 
specialized calculator, the kind that can compute the area of a circle. 
There are at least two different designs for such a calculator. 

• create a new class called AreaCalc2 with one method called rightTriangle with two input parame- 
tersof type double. This corresponds to designing a different area calculator with one button labeled 
rightTriangle with two input slots. 

• add to AreaCalc a method called rightTriangle with two input parameters of type double. This 
corresponds to designing an area calculator with two buttons: one labeled rectangle with two input 
slots and the other labeled rightTriangle, also with two input slots. 

In either design, it is the responsibility of the calculator user to pick the appropriate calculator or press the 
appropriate button on the calculator to correctly obtain the area of the given geometric shape. Since the two 
computations require exactly the same number of input parameters of exactly the same type, the calculator 
user must be careful not get mixed up. This may not be too much of an inconvenience if there are only two 
kinds of shape to choose from: rectangle and right triangle. But what if the user has to choose from hundreds 
of different shapes? or better yet an open-ende number of shapes? How can we, as programmers, buid a 
calculator that can handle an infinite number of shapes? The answer lies in abstraction. To motivate how 
conceptualize the problem, let us digress and contemplate the behavior of a child! 

1.1.2.2 Modeling a Person 

For the first few years of his life, Peter did not have a clue what birthdays were, let alone his own birth 
date. He was incapable of responding to your inquiry on his birthday. It was his parents who planned for 
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his elaborate birthday parties months in advance. We can think of Peter then as a rather "dumb" person 
with very little intelligence and capability. Now Peter is a college student. There is a piece of memory in his 
brain that stores his birth date: it's September 12, 1985! Peter is now a rather smart person. He can figure 
out how many more months till his next birthday and e-mail his wish list two months before his birth day. 
How do we model a "smart" person like Peter? Modeling such a person entails modeling 

• a birth date and 

• the computation of the number of months till the next birth day given the current month. 

A birth date consists of a month, a day and a year. Each of these data can be represented by an integer, which 
in Java is called a number of type int. As in the computation of the area of a rectangle, the computation 
of the number of months till the next birth day given the current month can be represented as a method 
of some class. What we will do in this case that is different from the area calculator is we will lump both 
the data (i.e. the birth date) and the computation involving the birth date into one class. The grouping of 
data and computations on the data into one class is called encapsulation. Below is the Java code modeling 
an intelligent person who knows how to calculate the number of months before his/her next birth day. The 
line numbers shown are there for easy referencing and are not part of the code. 

1 public class Person { 

2 /** 

3 * All data fields are private in order to prevent code outside of this 

4 * class to access them. 

5 */ 

6 private int _bDay; // birth day 

7 private int _bMonth; // birth month; for example, 3 means March. 

8 private int _bYear; // birth year 

9 /** 

10 * Constructor: a special code used to initialize the fields of the class. 

11 * The only way to instantiate a Person object is to call new on the constructor. 

12 * For example: new Person(28, 2, 1945) will create a Person object with 

13 * birth date February 28, 1945. 

14 */ 

15 public Person (int day, int month, int year) { 

16 _bDay = day; 

17 _bMonth = month; 

18 _bYear = year; 

19 } 

20 /** 

21 * Uses "modulo" arithmetic to compute the number of months till the next 

22 * birth day given the current month. 

23 * @param currentMonth an int representing the current month. 

24 */ 

25 public int nMonthTillBD(int currentMonth) { 

26 return (_bMonth - currentMonth + 12) °/ 12; 

27 } 

28 } 

(Download the above code 2 ) We now explain what the above Java code means. 



2 http://cnx.org/content/mll785/latest/Person.java 



line 1 defines a class called Person. The opening curly brace at the end of the line and the matching 

closing brace on line 28 delimit the contents of class Person. The key word public is called an access 

specifier and means all Java code in the system can reference this class. 

lines 2-5 are comments. Everything between /* and */ are ingored by the compiler. 

lines 6-8 define three integer variables. These variables are called fields of the class. The key word 

private is another access specifier that prevents access by code outside of the class. Only code inside 

of the class can access them. Each field is followed by a comment delimited by // and the end-of-line. 

So there two ways to comment code in Java: start with /* and end with */ or start with // and end 

with the end-of-line. 

lines 9-14 are comments. 

lines 15-19 constitute what is called a constructor. It is used to initialize the fields of the class to 

some particular values. The name of the constructor should spell exactly like the class name. Here 

it is public, menaing it can be called by code outside of the class Person via the operator new. For 

example, new Person(28, 2, 1945) will create an instance of a Person with _bDay = 28, _bMonth 

= 2 an d_bYear = 1945. 

lines 20-24are comments. 

line 23 is a special format for documenting the parameters of a metod. This format is called the javadoc 

format. We will learn more about javadoc in another module. 

lines 25-27 constitute the definition of a method in class Person. 

line 26 is the formula for computing the number of months before the next birthday using the remainder 

operator %. x % y gives the remainder of the integer division between the dividend x and the divisor 

y- 



1.2 Objects and Classes 3 

1.2.1 Objects 

In the "real" world, objects are the entities of which the world is comprised. Everything that happens in 
the world is related to the interactions between the objects in the world. Just as atoms, which are objects, 
combine to form molecules and larger objects, the interacting entities in the world can be thought of as 
interactions between and among both singular ("atomic") as well as compound ("composed") objects. The 
real world consists of many, many objects interacting in many ways. While each object may not be overly 
complex, their myriad of interactions creates the overall complexity of the natural world. It is this complexity 
that we wish to capture in our software systems. 

In an object-oriented software system, objects are entities used to represent or model a particular piece 
of the system. 

Objects are the primary units used to create abstract models. 

There are a number of schools of object-oriented programming, which differ slightly on how they view 
objects. Here, we will take a "behaviorist" (our term) stance: 

An object is characterized solely by it behaviors. 

Essentially this defines an object by the way it interacts with its world. An object that does not interact 
with anything else effectively does not exist. Access to internally stored data is necessarily through some 
sort of defined behavior of the object. It is impossible for an outside entity to truly "know" whether or not 
a particular piece of data is being stored inside of another object. 

NOTE: A beautiful example of a model that exhibits a particular behavior but without exactly 
replicating the mechanics we expect to produce that behavior is the "Dragon" optical illusion. A 
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printout to create this simple folded paper display can be found at the web site of the Grand 
Illusions Toy Shop in England 4 . 

This does not mean however, that an object may not contain data (information) in fields. The essence of 
the object is in how the object behaves in relationship to or as a result of its data, should it contain any. 

The existence of data in an object is an implementation technique used to generate 
the required behavior of that object. 

1.2.2 Classes 

Many objects differ from each other only in the value of the data that they hold. For example, both a 
red crayon and a blue crayon are crayons; they differ only in the value of the color attribute, one has a red 
color and the other a blue color. Our object-oriented system needs a way to capture the abstraction of a 
crayon, independent of the value of its color. That is, we want to express that a set of objects are abstractly 
equivalent, differing only in the values of their attributes and perhaps, thus differing in the behaviors that 
result from those values. 

Many objects are similar in many overall, generalized ways, differing only in smaller, more specific details. 
In biology and other fields, scientists organize objects into taxonomies, which are classification hierarchies 
used to express these similarities. For instance, a butterfly and a lobster are quite different, yet they share 
the common characteristics of all Arthropods, such as a jointed exoskeleton. The notion of an Arthropod 
enables us to understand and deal with butterflies and lobsters in an abstract, unified manner. So once again 
we are trying to express abstract equivalence. 

Object-oriented systems use classes to express the above notions of abstract equivalence. 

A class is an abstract description of a set of objects. 

A class thus contain the descriptions of all the behaviors of the objects that it represents. In computer 
science parlance, we call the individual behaviors of a class its methods. In addition, a class may, but not al- 
ways, contain descriptions of the internal data held by the objects, called its fields, as well as implementation 
details about its methods and fields. 

Turning the description around, we can say that a class is a template or recipe for the creation of 
a particular type of object. That is, one can use a class to create ("instantiate") objects of the type 
described by the class. Be careful not to make the very beginner's common mistake of equating classes and 
objects. A class is a specification of an set of objects, it is not the actual object. 

In technical terms, a class defines a new type in the system. Types are identifies used to differentiate 
different kinds of data. For instance, integers, characters, strings and arrays are all types of data. 

1.2.2.1 Implementation in Java 

Classes are the fundamtental building blocks of Java programs. Defining a class is basically a matter of 
specifying a name for the class, its relationship to other classes and what sort of behaviors the class exhibits 
as well as what data it may contain. 

SuppSuppose we wanted to define a class to describe a household pet. We could do it as such: 

class Pet { 
} 

The word class above is called a keyword and can only be used to state that the following code is the 
definition of a class. The class keyword is immediately followed by the desired name of the class, Crayon 
here. The curly braces, {...}, indicate the extent of the definition of the class. That is, any definitions of 
the class's behaviors and data will be found between the curly braces. Curly braces must therefore always 
appear as a matched set. 



4 http://www.grand-illusions.com/opticalillusions/dragon_illusion/ 



In general, in Java, curly braces mark the extent of a definition. 

NOTE: The accepted typographic standard in the Java community is that the opening curly brace 
is at the end of a line and the ending curly brace is at the beginning of its own line. Any code 
between the curly braces is indented. 

Well, our class for pets is simple, but not very interesting because it doesn't do anything. We could say 
that our pet has a name, but personally, I have found that the behavior of most pets is not affected by the 
particular name we give them. That is, we can give our pet a name but that doesn't change the way they 
behave. Let's try something else. 

Pets eat a certain amount of food per day. Pets have a certain weight. Let's create a model, that states 
that the number of hours that a pet sleeps per day is related to the amount of food they eat and their weight. 
Thus we could say that a pet has a behavior of sleeping a certain number of hours depending on its weight 
and the amount of food eaten. 

/** 

* A class that models a household pet 
*/ 

class Pet{ 

/** 

* The weight of the pet in lbs 
*/ 

double weight; 

/** 

* The number of hours the pet will sleep after eating 

* the given lbs of food. 

* @param lbsOfFood The number of lbs of food eaten. 

* ©return The number of hours slept after eating the food. 
*/ 

double hoursSlept (double lbsOfFood) { 

return 24. 0*lbsOf Food/weight ; 
} 
} 

But what about the pet's owner (a person, supposedly)? A person is not such a simple thing as a weight. 
Assigning a number to every possible person in the world is possible but not necessarily the most practical 
technique. There are many ways to represent people: the Registrar likes to think of you as a number with 
credit hours and unpaid bills, The CS department sees you as a 8-character login and unfinished graduation 
requirements, your doctor sees you as a collection of pulsating blood vessels, cells and bones, and your 
parents see you as this sweet little thing just out of diapers. A person is still a person, but the way that we 
choose to represent them may differ from situation to situation. 

But here's the crux of the issue: does your pet care how you are internally represented? Or does your 
pet just want something that is a person to be their owner? 

/** 

* A class that models a household pet 
*/ 

class Pet{ 

/** 

* The weight of the pet in lbs 
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*/ 
double weight; 

/** 

* The pet's owner 
*/ 

Person owner; 

/** 

* The number of hours the pet will sleep after eating 

* the given lbs of food. 

* @param lbsOfFood The number of lbs of food eaten. 

* ©return The number of hours slept after eating the food. 

*/ 

double hoursSlept (double lbsOfFood) { 

return 24. 0*lbsOf Food/weight; 
> 

/** 

* Determines whether or not this pet is happy to see a 

* particular person. 

* @param p The person who the pet sees . 

* ©return true if the Person is their owner, false otherwise. 
*/ 

boolean isHappyToSee (Person p) { 

return p == owner; 
} 
} 

Here we've added a field of type Person, which is a class used to represent people. It doesn't matter 
how Person is implemented, just that it is a representation of a person. We could use the class definition of 
Person that was created in the module on Abstraction (Section 1.1), or perhaps one that is fixed up a little 
bit, or perhaps a completely new one. The Pet doesn't care. 

Thus we see that objects can contain objects. What does this say about the possible complexity of a 
system of objects? 

1.2.3 Download code 

To download a zipped file containing the code above, click one of the following links: 

• DrJava Elementary Language Level code: DrJava_Code.zip 5 

• Standard Java code: Std_Java_Code.zip 6 

Both of the above codebases include a DrJava project file (.pjt) that can be opened from DrJava to easily 
manage all the code and test files. 



5 http://cnx.org/content/mll708/latest/Dr Java_Code.zip 
6 http://cnx. org/content /ml 1708/latest/Std_ Java_Code.zip 



1.3 Object Relationships 7 

An object-oriented system can be characterized as a system of cooperating objects. Some objects interact 
only with certain other objects or perhaps only with a certain set of objects. Sometimes objects are treated as 
equivalent even though there may be specific differences between them, for instance a situation may call for a 
"fruit" whereupon an "apple" will do just as well as an "orange". That is, apples and oranges are treated as 
abstractly equivalent. Conversely, the system designer may want to express the commonality between apples 
and oranges. An 00 system has two distinct mechanisms to express these relationship notions: "is-a" which 
is technically referred to as "inheritance" and "has-a" which is technically referred to as "composition". 



1.3.1 f? Is-a f? or "Inheritance" 

"Is-a" or "inheritance" (sometimes also called "generalization") relationships capture a hierarchal relation- 
ship between classes of objects. For instance, a "fruit" is a generalization of "apple", "orange", "mango" 
and many others. We say that fruit is an abstraction of apple, orange, etc. Conversely, we can say that since 
apples are fruit (i.e. an apple "is-a" fruit), that they inherit all the properties common to all fruit, such as 
being a fleshy container for the seed of a plant. 



UML Class Diagram Showing Inheritance 



Fruit 



5" 



































Apple 




Orange 




Manso 









Figure 1.1: The above diagram shows the "is-a" 
subclasses and the more abstract Fruit superclass. 



relationship between Apple, Orange and Mango 



NOTE: Classes are represented by boxes with the class name separated at the top by a horizontal 
line. 

NOTE: Inheritance ("is-a") lines are represented by solid lines with solid arrowheads. The arrow 
points from the subclass to the superclass (think "a subclass object is-a superclass object") 

In Java, inheritance relationships are declared using the extends keyword when declaring a class. A subclass 
"extends" a superclass, which means that the subclass is a concrete example of the more abstract superclass. 
For instance, the class Apple would extend the class Fruit. 



7 This content is available online at <http://cnx.org/content/mll709/!. 5/>. 
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public class Apple extends Fruit { 

} 

In Java, a subclass is allowed to extend only a single superclass (no "multiple inheritance"). This restricts 
the interpretation of a hierarchal taxomony. A subclass is an embodiment of its superclass. It is useful to 
think of the subclass as not inheriting its superclass's behaviors but rather possessing these behaviors simply 
because it is the superclass (this is polymorphism). Extend really models what an object intrinsically is- 
its true "being" as it were. This is particularly useful when the superclass has particular concrete behaviors 
that all the subclasses should exhibit. 

However, "is-a" can really be more of an "acts-like-a" relationship. This stems from the perspective 
that all objects are defined soley by their behaviors. We can never truly know what an object truly is, 
only how it acts. If two objects behave identically (at some abstract level) then we say that they are 
abstractly equivalent. What we need is a way to express the pure behavioral aspects of an object. Java 
has a the keyword implements which is used to show generalization of a pure behavioral abstraction called 
an interface. An interface has a similar syntax to a class, but only specifies behaviors in terms of the 
"signatures" (the input and output types) of the methods. For example we could have 

public interface ISteerable { 
public abstract void turnLeft(); 
public abstract void turnRightO; 
} 

public class Truck implements ISteerable { 

public void turnLeftO { 

// turn the tires to the left 

} 

public void turnRightO { 

// turn the tires to the right 

} 

} 

public class Boat implements ISteerable { 

public void turnLeftO { 

// turn the rudder to the left 

} 

public void turnRightO { 

// turn the rudder to the right 

} 

} 

NOTE: A public class, method or field can be seen and used by anyone. Contrasts with private 
(seen and used only by that class) and package (seen and used only by classes in the same package) . 
We'll talk more about these later. An abstract class or method is a purely abstract definition in 
that it specifies the existence of a behavior without specifying exactly what that behavior is. A 
void return type declares a non-existent return value, that is, no return value at all. 

Above, Trucks and Boats are not taxonomically related, but yet they both embody the behaviors of steer- 
ability, such as the ability to turn left or right. A person can pilot either a boat or a truck based soley on the 
fact that they both support turning left or right and not based on what sort of entity they are fundamentally. 
Note that as per the above definition, a class can implement multiple interfaces at the same time. 
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UML Class Diagram Showing Implementation 
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+ void : turnLeftQ 
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Truck 



+ void : turnLeftQ 
+ void : tumRightQ 



Figure 1.2: The above diagram shows the M acts-like-a M relationships between ISteerable, Boat, and 
Truck classes 



NOTE: Implementation ("acts-like-a") lines are represented by dotted lines with solid 
arrowheads. The arrow points from the subclass to the interface (think "a subclass object acts- 
like-a interface") 



1.3.2 "Has-a" or "Composition" 

"Has-a" or "composition" (sometimes referred to as an "associative") relationships capture the notion that 
one object has a distinct and persistant communication relationship with another object, for instance, we 
can say a car "has-a" motor. The car and the motor are not related in a hierarchal manner, but instead 
we need to be able to express that this pair of objects has a particular working relationship. The car gives 
gas to the motor and the the motor will propel the car along. Compositional relationships can be one-way, 
where one object can, in a persistant manner, talk to (i.e. call methods of) a second object but the second 
object cannot, in a persistent manner, talk back to the first object. Compositional relationships can also be 
two-way, where both objects can talk to each other in a persistent manner. 
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UML Class Diagram Showing Composition 




^ 



UTieel 



Figure 1.3: The above diagram shows the "has-a" relationships between the Car, Motor and Wheel 
classes 



NOTE: Composition ("has-a") lines are represented by solid lines with open arrowheads. 
The arrow points from the owner ("composite") to the ownee ("composee"). Think M a composite 
has a composee". The number at the arrowhead tells how many composees there are, e.g. 1, 2, etc. 
"*" means an limited number, so "0...* means zero or more and "1..*" means at least one. 

The emphasis made above with regards to persistent communication is deliberate and important. It is indeed 
possible for an object to communicate with another object in a non-persistent manner. Such non-persistent 
communication is generally not thought of as a compositional relationship, but rather as a dependency 
relationship where the action of one object depends on that of another. An object can tell a second object 
that it (the second object) needs to talk to a specific, perhaps third object. The second object does not know 
with whom it will be communicating until the first object tells it. The second object may not "remember" the 
object it is supposed to communicate with for any length of time after the communication was accomplished 
and the second object merely waits for the first object to tell it with whom to communicate next. This 
non-persistent communication is normally established by simply passing the third target object as an input 
parameter to the method call made on the second object by the first. Note that the third object could 
actually be the first object, creating a non-persistent two-way communication from an initially one-way 
communication. 



1.4 UML Diagrams 8 

Unified Modeling Language ("UML") is the industry standard "language" for describing, visualizing, and 
documenting object-oriented (00) systems. UML is a collection of a variety of diagrams for differing 
purposes. Each type of diagram models a particular aspect of 00 design in an easy to understand, visual 
manner. The UML standard specifies exactly how the diagrams are to be drawn and what each component 
in the diagram means. UML is not dependent on any particular programming language, instead it focuses 
one the fundamental concepts and ideas that model a system. Using UML enables anyone familiar with its 
specifications to instantly read and understand diagrams drawn by other people. There are UML diagram 
for modeling static class relationships, dynamic temporal interactions between objects, the usages of objects, 
the particulars of an implementation, and the state transitions of systems 
In general, a UML diagram consists of the following features: 



8 This content is available online at <http://cnx.org/content/mll658/!. 3/>. 
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• Entities: These may be classes, objects, users or systems behaviors. 

• Relationship Lines that model the relationships between entities in the system. 

• Generalization - a solid line with an arrow that points to a higher abstraction of the present 
item. 

• Association - a solid line that represents that one entity uses another entity as part of its 
behavior. 

• Dependency - a dotted line with an arrowhead that shows one entity depends on the behavior 
of another entity. 

1.4.1 Class Diagrams 

UML class diagrams model static class relationships that represent the fundamental architecture of the 
system. Note that these diagrams describe the relationships between classes, not those between specific 
objects instantiated from those classes. Thus the diagram applies to all the objects in the system. 
A class diagram consists of the following features: 

• Classes: These titled boxes represent the classes in the system and contain information about the 
name of the class, fields, methods and access specifiers. Abstract roles of the class in the system can 
also be indicated. 

• Interfaces: These titled boxes represent interfaces in the system and contain information about the 
name of the interface and its methods. 

• Relationship Lines that model the relationships between classes and interfaces in the system. 

Generalization 

* Inheritance: a solid line with a solid arrowhead that points from a sub-class to a superclass 
or from a sub-interface to its super-interface. 

* Implementation: a dotted line with a solid arrowhead that points from a class to the 
interface that it implement 

• Association - a solid line with an open arrowhead that represents a "has a" relationship. The 
arrow points from the containing to the contained class. Associations can be one of the following 
two types or not specified. 

* Composition: Represented by an association line with a solid diamond at the tail end. A 
composition models the notion of one object "owning" another and thus being responsible 
for the creation and destruction of another object. 

* Aggregation: Represented by an association line with a hollow diamond at the tail end. An 
aggregation models the notion that one object uses another object without "owning" it and 
thus is not responsible for its creation or destruction. 

• Dependency - a dotted line with an open arrowhead that shows one entity depends on the 
behavior of another entity. Typical usages are to represent that one class instantiates another or 
that it uses the other as an input parameter. 

• Notes that are used to provide further details or explanations of particular parts of the diagram. 
Notes are boxes with a little "dog-ear" on one corner. 

Here is an example of a UML class diagram that holds most of the more common features: 
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UML Class Diagram 



Host 



b- 



«njs^> 



+ Object : executeflListAIgo algo, Objecting) 



7T 



X 



M- 



zJEmptyUst?^ 



operates on 



calls on 



«MEList» 



+ Object : getFirstQ 
+ IList : getltestQ 



"J. 5" 



operates on 



W 



^TListAlgo^ 



+ Object : empty Case (JEmpty List host, Objecting) 
+ Object : nonEmptyCaseflNEList host, Objecting) 



Visitor 



^ 



Low level implementation L_^| 



Composite 



^ 



Empty List 



+ EinptyList : Singleton 



~ EinptyListQ 

+ Object : execute(IListAlgp algo, Object inp) 



.Singleton 



Calls algp.emptyCase(this, inp). 



^ 



-i- 



NEList 



™ Object : _first 
™ IList : rest 



+ NEList(Object first, IList tail) 

+ Object : getFirstQ 

+ IList : getRestQ 

+ Object : execute(IListAlgp algo, Object inp) 



Calls atog.nonErnptyCase(this ? inp). 



^ 



Figure 1.4: The above diagram contains classes, interfaces, inheritance and implementation lines, 
aggregation lines, dependency lines and notes. 



Chapter 2 

Polymorphism in Action 



2.1 Union Design Pattern: Inheritance and Polymorphism 1 

Inheritance and polymorphism (discussed below) are two sides of the same coin and represent very foun- 
dational concepts in object-oriented programming. The union design pattern is an expression of these 
relationships and enables us to talk about them in a more tangible manner. 

2.1.1 Union Design Pattern 

Consider the following "is-a" or inheritance relationships between "concrete" entities Coca Cola, sulfuric 
acid, milk and the "abstract" liquid (named "ALiquid" by convention since it is an abstract entity): 

Union of Liquids 



.iLiquid 



TV 



































CocaCola 




SulfurkAdd 




Milk 









Figure 2.1: ALiquid is the union of CocaCola, SulfuricAcid and Milk 



The UML diagram shows us that Coca Cola, sulfuric acid and milk are all liquids. Conversely, the 
diagram tells us that a liquid could be either Coca Cola, sulfuric acid or milk. Note of course, that liquids 
are not constrained to these 3 entities but that doesn't affect the discussion here-in fact, this will be an 
important feature later on. 

Another way that we can express the notions depicted by the diagram is to say that the abstract ALiquid 
superclass represents the union of Coca Cola, sulfuric acid and milk. That is, 



1 This content is available online at <http://cnx.org/content/mll796/!. ll/>. 
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a superclass represents the union of alio f its subclasses. 

or in other words 

a superclass represents all that is abstractly equivalent about its subclasses. 

For instance, the notion of an abstract liquid embodies all the behaviors and attributes such as having no 
definite shape, randomized atomic positions, freezing and boiling points that are common to Coca Cola, 
sulphuric acid and milk. Note the fine distinction between having a value and having the same value. 

NOTE: In general, an interface can be substituted for the abstract superclass discussed here with 
no loss of generality. 

The above diagram illustrating the relationship betwen a superclass and its subclasses is called the Union 
Design Pattern. The union pattern shows us inheritance in how the Coca Cola, sulfuric acid and milk 
will all inherit the abstract behaviors of liquids, such as the lack of a definite shape and freezing/boiling 
points. Conversely, it also shows that if a situation utilizes a liquid, either Coca Cola, milk or sulphuric 
acid can be used as they are all abstractly equivalent as liquids. Note that this does not imply that all 
three will act identically! For instance, the human throat can swallow any liquid because it is made to work 
with fluids that can flow. However, the reaction of the throat to sulphuric acid is markedly different than it 
reaction to milk! This ability to substitute any subclass for its superclass and get different behavior is called 
polymorphism. 

2.1.1.1 Abstraction vs. Commonality 

A subtle but extremely important point is that 

Commonality does not imply abstract equivalence. 

Just because a feature is common to every item in a set, does not necessarily mean that it represents some 
sort of abstract feature of those elements. For instance, cats, dogs, humans, and rats are all mammals where 
a mammal is defined as an animal that produces milk to feed its young. One could thus make a class model 
where a superclass Mammal has subclasses Cat, Dog, Human and Rat. One common feature is behavior is 
that cats, dogs, humans and rats all give live birth of their young. So it is tempting to say that the Mammal 
class should also embody the "live birth" behavior. However, as one wanders the world discovering new 
mammals, in the backwaters of Australia one finds the duck-billed platypus 2 which produces milk and is 
therefore clearly a mammal. However, the duck-billed platypus also lays eggs. Thus the "live birth" behavior 
does not belong in the Mammal superclass as it was only a coincidence that it was common to our initial set 
of subclasses. More importantly, being able to give live birth was never part of the abstract definition of a 
mammal and thus should never have been included in the Mammal superclass in the first place. 

Cats, monkeys and whales, while diverse creatures, are all mammals. Hence to model such a system in 
the computer, it makes sense to make Cat, Monkey and Whale all subclasses of an abstract Mammal superclass. 
Each species has many behaviors (methods) but I will only concentrate on 3 in particular: 

1. boolean givesMilkO : returns true if the animal can give milk to feed its young, false otherwise 

2. String makeSoundO : returns a String represenation of a common sound the animal makes. 

3. boolean givesLiveBirthO : returns true if the animal bears live young. 

In the table below are the methods and what happens when each species executes that method: 



2 http://www. creationscience.com/onlinebook/LifeSciencesl3. html 
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Mammal 


Method 


boolean givesMilkO 


String makeSoundO 


boolean 
givesLiveBirthO 


Cat 


true 


"Meow" 


true 


Monkey 


true 


"Screech" 


true 


Whale 


true 


"[whale song]" 


true 



Table 2.1 

We could start out with the following class implemenation (MammalO.java 3 ): 

Model of Mammals 



MflmmaJ 



7T 



Cat 



boolean : grvesMilk() 
String : mafeeSound() 
boolean : giviesLivieBirthO 



Monkey 



boolean : giviesMiIb() 
String : makjeSound() 
boolean : giviesLivieBirthO 



Whafe 



boolean : giviesMiIb() 
String : mafeeSoundO 
boolean : giviesLivieBirthO 



Figure 2.2: No common methods defined in the superclass. 



NOTE: Italics signify abstract methods or classes 

NOTE: return_value : method_name(parameter_type_#l parameter_name_#l, 

parameter_type_#2 parameter_name_#2 3 etc) 

Let's start our analysis: 

• A mammal is defined by the fact that it gives milk to feed its young. It is thus not surprising that 
all the givesMilkO methods in the subclasses return true. The givesMilkO method is a prime 
candidate for "hoisting" up into the Mammal superclass ("hoisting" = moving the method upwards 
from the subclass to the superclass). 

• makeSoundO returns a different value for each species, but intrisically, we expect any animal, which 
includes mammals, to be able to make some sort of sound. Thus Mammals should have a makeSoundO 
method, but since, at the Mammals level, we don't know exactly how that sound will be made, the 
method at that level must be abstract. The makeSoundO method at the concrete Cat, Monkey and 
Whale level however, would be concrete because each animal makes its own unique sound. 



3 http://cnx.org/content/mll796/latest/Mammal0.java 



18 



CHAPTER 2. POLYMORPHISM IN ACTION 



• givesLiveBirthO returns exactly the same value for all of our rather diverse selection of animals 
here. It seems like a fine candidate for hoisting. Or is it....? Let's go ahead an hoist it anyway. 

This is what we have so far (Mammal 1. Java 4 ): 



Model of Mammals 



Mammal 



boolean : grvesMilkO 
String : makefioundQ 
boolean : g^sLiveBirthQ 



S~ 



Abstract method denoted 
with italics. 



































Cat 




Monkey 




Whale 


String : makeSoundO 


String : makjeSoundO 


String : makeSoundO 



Figure 2.3: Abstract and common methods hoisted to the superclass. 



Before we go charging ahead, let's stop for a moment and review what we've done: Cats, monkeys, and 
whales do represent a wide spectrum of mammals, but remember, the abstract Mammal class is a representation 
of ALL mammals, not just the ones we have so far. The correlation of like behavior with all our represented 
animals does not imply its inclusion in their abstract representation! 

For instance, one day, in our wanderings through Australia, we encounter a Duckbilled Platypus 5 . Let's 
see how it behaves with respect to our 3 methods: 



Mammal 


Method 


boolean givesMilkO 


String makeSoundO 


boolean 
givesLiveBirthO 


Duckbilled Platypus 


true 


"growl" 


false 



Table 2.2 



Duckbilled platypus lay eggs!! 

Giving live birth is not part of the definition of a mammal. On the other hand, the question of whether 
or not the animal gives live birth can always be asked of any animal, including all mammals. The result may 
be true or false however, so the method must be abstract at the Mammal level. 

Our class structure should look like this (Mammal2.java 6 ): 



4 http://cnx.org/content/mll796/latest/Mammal0.java 
5 http://en.wikipedia.org/wiki/Duckbilled_platypus 
6 http://cnx.org/content/mll796/latest/Mammal0.java 
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Model of Mammals 



Mammal 



boolean : giviesMiIk() 
String : TnakeSoundQ 
boolean : givesLiveBirth Q 

























Cat 




Monkey 




Whale 




DucJAilledPlatypus 


String : makjeSoundO 
boolean : gjvesLivieBiithO 


String : makjeSoundO 
boolean : gjvesLivieBirthjO 


String : mataSoundO 
boolean : giviesLivieBirth() 


String : maJsaSoundjC) 
boolean : giviesLivieBirthjC) 



Figure 2.4: Properly abstracted model. 



Hoisting does not guarantee proper abstraction. Hoisting should be driven by a need for abstrac- 
tion, not by coincidence. 

Another key notion that the union pattern emphasizes is levels of abstraction. What we see is that 
the concept of a liquid is more abstract than milk. In turn, the general concept of milk is more abstract 
than "2% milk" or M skim milk" which would be subclasses of milk. In general we can see that a superclass 
is a distinctly higher level of abstraction than any of its subclasses. One of the key tools we use to help 
us design and build high quality object-oriented systems is careful attention to the abstraction level at any 
given moment. 

Good OOP code always maintains a consistent level of abstraction. 

Abstraction levels are links in a chain. A chain is only as strong as its weakest link. A program is only as 
abstract as its lowest abstraction level. 

Levels of abstraction illustrate another important aspect of an 00 program. Since a superclass represents 
the union of the subclasses or conversely, that the superclass can be represented by any of its subclasses, 
we see that the superclass is an embodiment of all the invariant aspects of the subclasses. That is, the 
superclass's definition is all that is abstractly equivalent about the sub classes-all that does not change from 
subclass to subclass. Note that this does not imply that the values of common fields are necesarily the 
same, just that, perhaps, that the field exists. Not does it imply that what is common to all the subclasses 
is necessarily what is abstractly equivalent about them (see the note above). The differences between the 
subclasses is what creates the variations in how the program behaves when any given subclass is used in 
place of the superclass. We call this the variant aspects of the system. 

The total behavior of a program is the combination of its variant and invariant behaviors. 



2.1.2 Inheritance and Polymorphism 

Inheritance and polymorphism are really just two ways of looking at the same class relationship. 

Inheritance is looking at the class hierarchy from the bottom up. A subclass inherits behaviors and 
attributes from its superclass. A subclass automatically possesses certain behaviors and/or attributes simply 
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because it is classified as being a subclass of an entity that possesses those behaviors and/or attributes. That 
is, a cherry can be said to automatically contain a seed because it is a subclass of Fruit and all fruit contain 
seeds. 

Inheritance is useful from a code reuse perspective. Any (non-private) code in the superclass does not 
have to be replicated in any of the subclasses because they will automatically inherit those behaviors and 
attributes. However, one must be very careful when transferring common code from the subclasses to the 
superclass (a process called "hoisting"), as the proper abstraction represented by the superclass may be 
broken (see note above). 

Polymorphism, on the other hand, is looking at the class hierarchy from the top down. Any subclass 
can be used anywhere the superclass is needed because the subclasses are all abstractly equivalent to the 
superclass. Different behaviors may arise because the subclasses may all have different implementations 
of the abstract behaviors defined in the superclass. For instance, all liquids have a boiling temperature. 
They may have different values for that boiling temperature which leads to different behaviors at any given 
temperature. 

Polymorphism is arguably the more useful perspective in an object-oriented programming paradigm. 
Polymorphism describes how an entity of a lower abstraction level can be substituted for an entity of a 
higher abstraction level and in the process, change the overall behavior of the original system. This will be 
the cornerstone that enables us to build 00 systems that are flexible, extensible, robust and correct. 

2.1.3 Exploring Polymorphism 

Let's explore some different ways in which polymorphism presents itself. Consider the following example of 
the union design pattern: 

/** 

* An interface that represents an operation on two doubles 

*/ 

public interface IBinaryOp { 

double apply ( double x, double y) ; // all interface methods are public and abstract by default 

} 

/** 

* An IBinaryOp that adds two numbers 
*/ 

public class AddOp implements IBinaryOp { 
public double apply ( double x, double y) { 
return x+y; 

/** 

* An IBinaryOp that multiplies two numbers 

*/ 

public class MultOp implements IBinaryOp { 
public double apply ( double x, double y) { 
return x*y; 
} 

public String getDescriptionO { 

return "MultOp is a multiplying function."; 

} 
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Exercise 2.1 (Solution on p. 35.) 

Is the following legal code? IBinaryOp bop = new IBinaryOpO ; 

Exercise 2.2 (Solution on p. 35.) 

Is the following legal code? IBinaryOp bop = new AddOpO; 

Exercise 2.3 (Solution on p. 35.) 

Given the above declaration and assignment of bop, is the following assignment then possible? bop 
= new Mult Op (); 

Exercise 2.4 (Solution on p. 35.) 

Suppose we have bop = new AddOpO; , what is the result of bop. apply (5, 3) ? 

Exercise 2.5 (Solution on p. 35.) 

Suppose we now say bop = new MultOpO, what is the result of bop. apply (5, 3) now? 

Exercise 2.6 (Solution on p. 35.) 

Suppose we have some variable, called my Op of type IBinaryOp what is the result of 
myOp . apply (5,3)? 

Exercise 2.7 (Solution on p. 35.) 

Suppose we have bop = new MultOpO, is it legal to call bop.getDescriptionO ? 

Exercise 2.8 (Solution on p. 35.) 

Is the following legal code? AddOp aop = new AddOpO 

Exercise 2.9 (Solution on p. 35.) 

Given the declaration in the previous exercise, is the following legal? aop = new MultOpO 

Exercise 2.10 (Solution on p. 35.) 

Suppose we have definitions of aop and bop from above. Is the following legal? That is, can we 
compile and run the folowing statement without error? bop = aop ; 

Exercise 2.11 (Solution on p. 35.) 

Is the converse legal as well? That is, using the above definitions, can we compile and run the 
following statement? aop = bop; 



2.2 Ballworld, inheritance-based 7 

In this module we will explore many OOP concepts by examining the program "Ballworld". Download the 
code for Ballworld here 8 . 



7 This content is available online at <http://cnx.0rg/content/mll8O6/l. 7/>. 
8 http://cnx.org/content/mll806/latest/Ballworld.zip 
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CHAPTER 2. POLYMORPHISM IN ACTION 
UML class diagram of Ballworld 



XoOpLambda 



+ XoOpLambda : Singleton 



' XoOpLam'adaO 

' Object : apply(Object arg) 



■ Objeci opph 'Objecai-g: 



BallControl 



1 IRandomLzer : rand 
1 int : _Ma.iRadius 
1 int : _MinRadius 
1 int : _MasSpeed 
1 Rectangle : _MaxVel 
■ BallGLl : Jrame 
1 Dispatcher : _dispatcher 
1 ELambda : _paintCmd 
1 ELambda : jnakeBallCmd 
1 ELambda : _clearBallsCmd 
1 int : TimeSlice 
1 Timer: timer 



BaHControK) 

ABall : loadBall(String className) 

i- 



' JPanel : _controlPnl 

' ELambda : _paintCmd 

' JPanel :_ca:-.vi:P:'.'. 

■ JButton : _malffiBallBtn 

■ JButton : _cleariUlBtn 
' ,"?;:■: :F-.;'.d : _inputTF 



+ Ei'.'.O-UI :::\i. ILi:n'ada makeBallCmd. final ELambda clearBallsCmd. ELambda paintCmd) 

— void : initO 

ff void : process T .VindO'.YEvent(V,,"indo^vE l .Tent e) 

+ Container : get:" :■:.:;:.;: : 



instantiates subclass of 
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Dispatcher 



+ ■■:■■.; ::.-'[:fyAjI j :■;;■:: yi: ;::i : 



di^atchesjfl 



j 



«Dtandomi 



1 Point : randomLoc(Rectangle rect) 

• Point : randomLoc(Dlmenslon dim) 

• int : rondomlnt(int mm, Int max) 

1 double : randomDouble(double mln, double max) 

1 ."■;■:■;: ■:.';■;.[;;:: 

1 Dimension : randomDim(Dimension maxDlm) 

1 Rectangle : randomBoundsi'Rectangle reel. Dimension maxDlm) 

1 Color : randomCoiorf) 

1 O'.ir. ': .1 : \" ■_". -:". '-". ;■:: ■: . ; : :..'.'■ 



~w 



■ Point : location 
1 int : radius 
1 Point : velocity 
1 Color : color 
1 Container 



1 ABall(Point p. int r. Point v. ; :'.:■: ■:. ; Vitamer container) 

1 void : update(Observable o, Object g) 

1 void : bounceQ 

1 void : setLocationfPoint location) 

1 Point :getLo:; :■.::'. : 

1 void : setRadius(int radius) 

1 int : getRadiusO 

1 void : setVelocity(Point velocity) 

■ Point : getVelocityO 

1 void : setColor(Color color) 

■ Color : getColorO 

1 void : paint(Graphics g) 
1 \otd: upda:eS:a:e-'j 



1 ERandomizer : i 
1 int : delta 



+ WanderBall(Point p = int r, Point v, Color c. Container container) 
+ void: upd;:; : .. tit; : 



- 



■ RandomizerO 

■ Point : randomLoc(Rectangle rect) 

■ Point : randomLoc(Dimension dim) 

■ int : randomInt(int rain, int mai) 

■ double : randoniD ;■;.':.-'.; i. ?:■':'.? min. double mai) 

■ Point : randomVel(Pjectangle rect) 

■ Dimension : randomDimCDimension maiDim) 

■ R;::i:'.;'.; :i::i:::iE ::.:'.::■ F. ?■::;:-.:'.;:;;:. D-.::i ?:■.:■- 3:: :ni:;D-.:ri : 

■ Color : randomColorQ 

■ Object : randomChoicef.OVect :■;. Object y. double probX) 



StraightBall 



■ ; jt:Sip:E;'.', P ?■.:.: i\ :■;.: -.. P :-.:.: v. Z :'.:: ■:. Z y;.:i:-:=: ■::■:'. :;-■;: ■ 

■ void : updateStateQ 



' ERandomizer : rand 

■ double : angle 

■ double : cosA 

■ double : sinA 



■ ^:-;E;" P :-.:'.: _\ ■.:■.: :. P :-.:'.: v. Z Sio: ■:. Z :■:'. :;■.:'.;: ::■:.:;.:;: : 

■ void: updat; kit? ; 



Figure 2.5: Note the union design pattern w.r.t. ABall and its subclasses. 



To run Ballworld, load the files into DrJava and right-click the BallControl file. Select "Run Document's 
Main Method" to run the program. From the command line, go to the uppermost Ballworld directory 
and compile all the files in both the directories ("javac ballworld/*. Java" and "javac command/*. Java") and 
then run the program as such: "Java ballworld. BallControl" . The Make Ball button creates an instance of 
whatever ABall class is typed into the text field on the left. The "Clear All" button clears any balls off of 
the screen. 

In a nutshell, the way Ballworld works is akin to a flip-book animation: The BallControl class contains 
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a Timer that "ticks" every 50 milliseconds. Every time the timer ticks, the panel in the BallGUI upon which 
the balls are to be drawn is requested to repaint itself. When the panel repaints, it also tells the Dispatcher 
to notify every ABall in the system to update itself. When an ABall updates, it updates any internal 
values it has (its "state") such as its color, radius, and/or velocity. It then moves its position by an amount 
corresponding to its velocity and draws ("paints") itself onto the panel. Since this is happening 20 times a 
second, the balls appear to be moving and/or changing and thus the animation is acheived. The ILambda 
interface3 enables the BallGUI to communicate in a generic, decoupled manner to the BallControl and 
the Randomizer class is a utility class that provides methods to produce various random values needed by 
the system. Much of the code in Ballworld is significantly more sophisticated than what has been covered 
in the course so far-it will be covered soon, don't worry! 

2.2.1 Abstract Classes 

First, we will focus on the union design pattern between ABall, WanderBall, CurveBall and StraightBall. 
In a union design pattern, we see that the superclass represents an abstraction of the union of its subclasses. 
For instance, a fruit is an abstraction of specific concrete classes such as apple and pear. A fruit embodies 
the common characteristics of its subclasses even if it doesn't completely describe the exact nature of those 
characteristics. In a fruit, there is a seed. However, the notion of "fruit" doesn't specify exactly the number, 
size, color or shape of its seed(s). It only specifies that it does indeed have a seed. Likewise, a fruit has the 
behavior of ripening. Apples, oranges, and bananas all ripen differently and at different rates. The abstract 
fruit notion does not specify the specific nature of the ripening behavior, just simply that it does have that 
behavior. In such, we see that we can never have a fruit that is not a specific class of fruit, such as an orange 
or grape. 

Corresponding to the above notions, abstract classes in Java cannot be instantiated. Abstract classes are 
denoted by the abstract keyword in the class definition: 

public abstract class AFruit {...} 

By convention, the classnames of abstract classes always begin with "A". 

In Ballworld, ABall is an abstract class representing a circular ball that has a number of properties: a 
color, a position, a velocity, etc. The abstract ball also has some defining behaviors, such as that all balls 
should paint a filled, colored circle when requested to display themselves on a graphics context (a panel). 
Likewise all balls know how to bounce off the walls of the container. These concrete behaviors are called 
"default behaviors" because all subclasses of ABall, such as StraightBall and CurveBall, automatically 
get these behaviors by default. One of the most common and useful reasons for using an abstract class is to 
be able to define the default behaviors for all the subclasses. 

2.2.1.1 Abstract Methods 

But what about the abstract behaviors that abstract classes exhibit? For instance the abstract "ripening" 
behavior of a fruit? At the abstraction level of a fruit, the exact implentation of ripening cannot be specified 
because it varies from one concrete subclass to another. In Java, this is represented by using the keyword 
abstract as part of the signature of a method which has no code body: 

public abstract class AFruit { 
// rest of the code 

public abstract void ripen () ; 
} 

There is no code body because it cannot be specified at this abstraction level. All that the above code says 
is that the method does exist in all AFruit. The specific implmentation of method is left to the subclasses, 
where the method is declared identically except for the lack of the abstract keyword: 



24 CHAPTER 2. POLYMORPHISM IN ACTION 



public class Mango extends AFruit { 
// rest of code 

public void ripen() { 

// code to ripen a mango goes here 

} 

} 

public class Tomato extends AFruit { 
// rest of code 

public void ripend() { 

// code to ripen a tomato goes here 

} 

} 

The technical term for this process is called overriding. We say that the concrete methods in the subclasses 
override the abstract method in the superclass. 

Note that if a class has an abstract method, the class itself must be declared abstract. This simply 
because the lack of code in the abstract method means that the class connot be instantiated, or perhaps more 
importantly, it says that in order for a class to represent abstract behavior, the class itsefl must represent 
an abstract notion. 

Overriding is not limited to abstract methods. One can override any concrete method not declared with 
the final keyword. We will tend to avoid this technique however, as the changing of behavior as one changes 
abstraction levels leads to very unclear symantics of what the classes are actually doing. 

In Ballworld we see the abstract method updateState. Abstract methods and classes are denoted in 
UML diagrams by italic lettering. This method is called by the update method as part of the invariant 
process of updating the condition of the ball every 50 milliseconds. The update method does 4 things: 

1. Update the state of the ball by calling the abstract updateState method. 

2. Move (translate) the position of the ball by adding the velocity to it. 

3. Check if the ball needs to bound off a wall. 

4. Paint the ball up on the screen. 

This technique of calling an abstract method from inside of a concrete method is called the template 
method design pattern-which we will get to later in the course. 

ABall.updat eState () is abstract because at the abstraction level of ABall, one only knows that the 
ball will definitely do something with regards to modifying (perhaps) its internal field values (its "state"). 
Each subclass will do it differently however. The StraightBall will do nothing in its updateState method 
because a ball with a constant (unchanging) velocity will travel in a straight line. Remember, doing nothing 
is doing something! The CurveBall's updateState method uses sines and cosines to turn the velocity 
by a fixed (though randomly chosen) angle at every update event. You can imagine that other possible 
subclassses could do things such as randomly change the velocity or change the radius of the ball or change 
the color of the ball. 

There is no code in the entire Ballworld system that explicitly references any of the concrete ABall 
subclasses. All of the code runs at the level of abstraction of an abstract ball. The differences in behavior of 
the various balls made on the screen using the different concrete subclasses is strictly due to polymorphism. 
New types of balls can be added to the system without recompiling any of the existing code. In fact, new 
types of balls can be added without even stopping the Ballworld program! 
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2.2.2 Abstract classes vs. Interfaces 



Subclasses have a different relationship between interfaces and abstract superclasses. A subclass that imple- 
ments an interface is saying simply that it "acts like" that specified by the interface. The class makes no 
statements however about fundamentally what it actually is. An actor implements a fiercesome alien from a 
distant plantet in one movie and a fickle feline in another. But an actor is actually neither. Just because the 
actor protrayed a interplanetary alien, doesn't mean that the actor fundamentally possessed all the abilities 
of such an alien. All it says is that in so far the context in which the actor was utilized as the alien, the 
actor did implement all the necessary behaviors of the alien. 

A subclass is fundamentally an example of its superclass. A subclass automatically contains all the 
behaviors of its superclass because it fundamentally is the superclass. The subclass doesn't have to implement 
the behaviors of its superclass, it already has them. An actor is a human and by that right, automatically 
possesses all that which makes a human: one head, two arms, 10 toes, etc. Note that this is true even if the 
abstract class has 100% abstract methods-it still enforces a strict taxonomical hierarchy. 

implements is about behaving, extends is about being. 

2.2.3 Variant vs. Invariant Behaviors 

A crucial observation is that the the Ballworld code that manages the GUI (BallGUl) and the ball man- 
agement (BallControl, Dispatcher, etc.) only deal with the abstract ball, ABall. That is, they represent 
invariant behavior at the abstract ball level. The display, creation and managment of the balls is indepen- 
dent of the particular kinds of concrete balls that is being handled. The main Ballworld framework can thus 
handle any type of ABall, past, present and future. 

StraightBall, CurveBall and WanderBall are thus concrete variants of ABall. They represent the 
variant behaviors of the system. Other than in their constructors (which will prove to be a significant 
point when this inheritance-based model is compared to a more advanced composition-based model), these 
concrete subclasses only code the abstract variant behavior associated with a ball, namely the updateState 
method. Inheritance gives any instantiation of these classes both the invariant behaviors from the ABall 
superclass plus the variant behaviors from the subclass. 

The Ballworld code demonstrates the importance of the concept of separation of variant and invariant 
behaviors. 

Clearly and cleanly separating the variant and invariant behaviors in a program is crucial for 
achieving flexible, extensible, robust and correct program execution. 

Where and how to separate the variant and invariant behaviors is arguably the most important design 
consideration made in writing god software. 

2.2.4 Java Syntax Issues 

2.2.4.1 Packages 

Packages are way that Java organizes related classes together. Packages are simply directories that contain 
the related code files. Each class file in a package directory should have the line package XXX; at its top, 
where the XXX matches with the directory, name. If neither public nor private (nor protected - i.e. a 
blank specifier) is used to specify the visibility level of a class or method, then that method can be seen by 
other members of the package but not by those outside of the package. To use the public classes in a package, 
the import myPackage . * ; syntax is used. This tells the Java compiler to allow all the public classes in the 
myPackage directory. Packages can be nested, though each level must be imported separately. 
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2.2.4.2 Static fields and methods 

Static fields and methods, denoted by the static keyword in their declarations, are fields and methods that 
can be accessed at a class level, not just an object level. In general these are values or behaviors that one 
wishes for all instances of a class to have access to. These values and behaviors are necessarily independent 
of the state of any particular instance. Static fields and methods are often referred to as "class variables" 
and "class methods". 

An examples of a class variables are Math. PI and Color .BLUE or Color. RED. These are universal values 
associated with math and color respectively and thus do not need an object instance to be viable. By 
convention, all static field names are in all capitol letters. A static field is referenced simply by writing the 
class name followied by a period and then by the field name. No instantiations are necessary. 

The Randomizer class contains numerous static methods. This is because each of the methods to produce 
various random values is independent of each other and that the process in each method does not affect nor 
is affected by the state of the rest of the class. Essentially, this entails that the class contain no non-static 
fields. A class as such is referred to as being "stateless". Just like a static field, a static method is invoked 
in the same manner as the static fields: ClassName . staticMethodName (...) Classes with static methods 
are usually utility classes that are used to hold a set of related functional processes, e.g. Randomizer holds 
a collection of random value generators. Likewise, Math holds a combination of static values, such as PI 
and static methods such as sinQ and cos(). 

There is one very special static method with the following exact signature: 

public static void main (String [] args) 

This method, found in BallControl, is the method that Java uses to start programs up. Since 00 programs 
are systems of interacting objects, this static "main" method is used to create the first object (s) and get the 
program up and running. So when Java starts a program, it looks for this and only this method. 

2.2.4.3 Calling methods of the superclass 

When concrete methods or the constructor of a superclass are overriden, sometimes it is necessary or desirable 
to call the original superclass behavior from the subclass. A common reason for this is that the subclass's 
behavior is simple an addition to the superclass behavior. One does not want to replicate the superclass 
code, so a call to the superclass's original methods is required at some point in the subclasses overriding 
method. To accomplish this, Java uses the super keyword, super refers to the superclass instance, just 
as this refers to the class instance itself (the subclass here). Note that technically, super and this are 
the same object - think of it as the difference between the id and the ego. (Does that mean that a coding 
mistake wiith respect to super and this is a Freudian slip?) 

Suppose the superclass has a method called myMethodO which the subclass overides. For the subclass 
to call the superclass's myMethod, it simply needs to say super .myMethodO . Contrast this to the subclass 
calling its own myMethod: this. myMethodO (note: Java syntax rules allow for the this to be omitted). 

To make a call to the superclass's constructor the subclass simply says super ( . . . ) , supplying wahtever 
parameters the superclass constructor requires. This is a very common scenario as the the subclass almost 
always needs to superclass to initialize itself before it can perform any additional initializations. Thus the 
super ( . . . ) call must be the first line in the subclass's constructor. If the no-parameter constructor of the 
superclass is required, the call to super can be omitted as it will be automatically performed by the Java 
run-time engine. This of course presumes that the superclass's no-parameter constructor exists, which it 
does not if a parameterized constructor has been declared without explicitly declaring the no-parameter 
constructor. 
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2.3 Ballworld, composition-based 9 

In this module we will explore what is gained by modifying the inheritance-based Ballworld system (Sec- 
tion 2.2) into a composition-based system. 

In the inheritance-based Ballworld system, we were able to generate quite a bit of flexibility and extensi- 
bility. For instance, we could develop new kinds of balls and add them into the system without recompiling 
the rest of the code. This was accomplished by having the invariant ball creation and management code deal 
only with the abstract ball while the variant behaviors were encapsulated into the concrete subclasses. 

2.3.1 The Problem with Inheritance 

Inheritance seems to work quite well, but suppose we want to do more than just put different kinds of balls 
on the screen? What if we wanted to be able to change how a ball behaves, after it has been created? What 
if we want create balls that do a multiple of different behaviors, such as change color and radius? While 
working solutions using an inheritance-based system do exist, they are cumbersome, inefficient and most 
importantly, inconsistent with any sort of clear abstract model of what balls should be like. 

The problem lies in the very nature of inheritance. When we attempted to separate the variant from the 
invariant behaviors, we overlooked a crucial aspect of inheritance. In our model, the superclass represented 
the invariant behaviors of a ball while the subclasses represented the variant behaviors. The separation 
seemed clear enough in the UML diagram, except that when one has an actual object instance, both the 
superclass and subclass behaviors are bound into a single entity. A ball object cannot change its variant 
updateState behavior because it is inextricably bound with to the invariant behaviors. A ball object cannot 
be composed of multiple updateState behaviors because that code cannot be isolated from the rest of the 
ball's code. If you want a curving behavior, you have to get it packaged in a whole ball object -you can't get 
just the behavior. 

A clear sympton of this problem is the common code to call the superclass constructor found in all the 
subclasses' constructors. This tells us that the superclass is really right there in the subclass with everything 
else. The fact that the code is repeated from class to class says that it is invariant code in the middle of 
what we want to be variant code. 

The inheritance-based model of Ballworld does not separate the variant and the invariant at the 
proper place. There is invariant code mixed together with the variant code. 

That's why they can't be separated and the invariant behaviors are dragged along with the variant behaviors. 
This is what makes dynamically changing behaviors and multiply composed behaviors so difficult in this 
system. 

2.3.2 Pizzas and Shapes 

To understand what we can do to remedy the problems with our inheritance-based model, let's digress for 
a bit and consider a simple model of pizzas. Here, we have a pizza which has a price and has a shape. A 
shape, be it a circle, square, rectangle of triangle, is capable of determining its own area. A pizza, when 
requested to calculate its price per square inch, simply takes its price and divides it by the area of its shape. 
To obtain that area, the Pizza delegates to the I Shape, since it is the shape that knows how to calculate 
its area, not the pizza. 



9 This content is available online at <http://cnx.org/content/mll816/!. 5/>. 
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Figure 2.6: A pizza has-a shape, which is able to calculate its area. 



Delegation is the handing of a calculation off to another object for it process. Here, the pizza is only 
interested in the result of the area calculation, not how it is performed. 

To the pizza, the shape represents an abstract algorithm to calculate the area. 

The Pizza and the IShape classes represent the invariant processes involved with calculating the price 
per square inch ration, while the concrete Circle, Square, Triangle and Rectangle classes represent the 
variant area calculations for different shapes. What wee see from this example is that 

objects can be used to represent pure behavior, not just tangible entities. 

Interfaces are particularly useful here as they are expressly designed to represent pure, abstract behavior. 

2.3.3 From Inheritance to Composition 

Coming back to Ballworld, we see that the updateState method in ABall is an abstract algorithm to 
update the state of the ball. So, just as in the pizza example, we can represent this algorithm, and just 
this algorithm, as an object. We can say that a ball has an algorithm to update its state. Another wa 
of saying this is to say that the ball has a strategy to update its state. We can represent this by using 
composition. Instead of having an abstract method to update the state, we model a ball as having a reference 
to an IUpdateStrategy object. The code for update thus becomes 



public void update (Observable o, Object g) 
{ 

.strategy .updateState (this) ; // update this ball's state using the strategy 
location. translate (velocity. x, velocity. y); // move the ball 
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} 



bounce (); // bounce the ball off the wall if necessary 
paint ((Graphics) g) ; // paint the ball onto the container 



The ball hands a reference to itself, this, to the strategy so that the strategy knows which ball to update. 
The variant updating behaviors are now represented by concrete implementations of the IUpdateStrategy 
interface. 

Composition-based Ballworld 
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Figure 2.7: Ball is now a concrete class and its subclasses have been eliminated in favor of being 
composed with an abstract strategy. 



(Note that the Randomizer class has been redesigned to eliminate its static methods. One new method 
has been added as well.) 

There are a number of very important points to notice about this new formulation: 

• The modified ABall class now contains 100% concrete code and thus should not be abstract anymore. 



• ABall has been renamed to simply Ball. 

• Accessor methods for the strategy (getStrategy and setStrategy) have been added. 
The Ball class is still 100% invariant code. 
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• The CurveBall, StraightBall, etc. subclasses are no longer needed as their variant behaviors have 
been moved to the IUpdateStrategy subclasses. 

• Effectively what has happened is that the updateState method has been moved from the ABall 
subclasses and embodied into their own classes. 

• The IUpdateStrategy subclasses do not inherit anything from Ball, hence they do not contain 
any invariant code. 

• The strategies are thus 100% variant code. 

• The reference to the ball during the updating process has gone from a peristent communication link 
(implicitly, this), to a transient communication link (host). 

• This composition-based model divides the code exactly between the variant and invariant behaviors- 
this is the key to the power and flexibility it generates. 

This new composition-based model of Ballworld is an example of the Strategy Design Pattern 10 . The 
strategy design pattern allows us to isolate variant behaviors on a much finer level than simple inheritance 
models. 

2.3.3.1 Composing Behaviors 

So far, all of our redesigning has resulted in a system that behaves exactly as it did when we started. But 
what one finds very often in developing systems is that in order to make two steps forward, one must first 
make one step backwards in order to fundmentally change the direction in which they are going. So, even 
though it looks like our system has not progressed because it still does exactly the same thing, we are indeed 
in a very different position, architecturally. By freeing the variant behaviors from the invariant ones, we 
have generated a tremendous amount of flexibility. 

2.3.3.1.1 Balls that change their strategies 

Let's consider a the notion of a ball that changes its behavior. Since we have modeled a ball as having a 
strategy, we can simply say that in some manner, it is the ball's strategy that changes. We could say that 
the ball changes its strategy, but since the ball doesn't know which strategy it has to begin with, it really 
doesn't know one strategy from another. One could argue that it therefore can't know when or if it should 
ever change its strategy. Therefore, the ball cannot be coded to change its own strategy! So, whose baliwick 
is the changing of the strategy? 

Since the changing of a strategy is a strategy for updating the ball, it is the strategy that determines the 
change. The strategy changes the strategy! Let's consider the following strategy: 

package ballworld; 
import j ava . awt . * ; 

public class Change 1 Strategy implements IUpdateStrategy { 

private int i = 500; // initial value for i 

public void updateState (Ball context) { 

if(i==0) context . setStrategy (new CurveStrategyO) ; // change strategy if i reaches zero 
else i--; // not yet zero, so decrement i 



D http://www. exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern. htm 
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This strategy acts just like a Straight Strategy for 500 updates and then it tells the ball (its context) 
to switch to a CurveStrategy. Once the CurveStrategy is installed, the ball becomes curving, without 
the need for any sort of conditionals to decide what it should do. The context ball fundamentally and 
permanently becomes curving. 

Exercise 2.12 (Solution on p. 35.) 

What would happen if you had two strategies like the one above, but instead of replacing themselves 
with CurveStrategy's , they instead instantiated each other? 

A key notion above is that a strategy can contain another strategy. In the above example, the 
Change 1 Strategy could have easily pre-instantiated the CurveStrategy and saved it in a field for use 
when it was needed. But the does it matter exactly which concrete strategy is being used? If not, why 
not work at a higher abstraction level and let one strategy hold a reference to an abstract strategy? For 
instance, consider the following code: 

package ballworld; 
import j ava . awt . * ; 

public class SwitcherStrategy implements IUpdateStrategy { 

private IUpdateStrategy .strategy = new StraightStrategyO ; 

public void updateState(Ball context) { 

.strategy. updateState (context) ; 
} 

public void setStrategy( IUpdateStrategy newStrategy) { 

.strategy = newStrategy; 
} 
} 

This strategy doesn't look like it does much, but looks are deceiving. All the SwitcherStrategy does is to 
delegate the updateState method to the .strategy that it holds. This does not seem much in of itself, 
but consider the fact that the SwitcherStrategy also has a settor method for .strategy. This means 
that the strategy held can be changed at run time! More importantly, suppose a ball is instantiated with 
a SwitcherStrategy. The behavior of the ball would be that of whatever strategy is being held by the 
SwitcherStrategy since the switcher just delegates to the held strategy. If one were to have a reference to 
that SwitcherStrategy instance from somewhere else, one could then change the internal strategy. The ball 
is none the wiser because all it has is a reference to the SwitcherStrategy instance, which hasn't changed 
at all! However, since the held strategy is now different, the ball's behavior has completely changed! This 
is an example of the Decorator Design Pattern 11 , where the SwitcherStrategy class is formally called the 
decorator and the held strategy is formally called the decoree. In theoretical terms, the decorator is what 
is known as an indirection layer, which is like a buffer between two enities that enables them to depend 
on each other but yet still be free to move and change with respect to each other. A very useful analogy 
for indirection layers is like the thin layer of oil that will enable two sheets of metal to slide easily past each 
other. 

2.3.3.1.2 Balls with multiple, composite behaviors 

Now that we can dynamically change a ball's behavior, let's tackle another problem: 



1 http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/DecoratorPattern.htm 
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Exercise 2.13 (Solution on p. 35.) 

How can we have balls with multiple behaviors but yet not duplicate code for each one of those 
behaviors? 

Let's start with a very straightforward solution: 

package ballworld; 
import j ava . awt . * ; 

public class DoubleStrategy implements IUpdateStrategy { 

private IUpdateStrategy _sl = new CurveStrategyO ; 

private IUpdateStrategy _s2 = new BreathingStrategyO ; 

public void updateState(Ball context) { 

_sl .updateState (context) ; 

_s2.updateState (context) ; 
} 
} 

Ta da! No problem. The DoubleStrategy simply holds two strategies and delegates to each of them in turn 
when asked to updateState. So why stop here? 

package ballworld; 
import j ava . awt . * ; 

public class TripleStrategy implements IUpdateStrategy { 

private IUpdateStrategy _sl = new CurveStrategyO ; 

private IUpdateStrategy _s2 = new BreathingStrategyO ; 
private IUpdateStrategy _s3 = new BreathingStrategyO ; 

public void updateState (Ball context) { 

_sl .updateState (context) ; 

_s2. updateState (context) ; 

_s3. updateState (context) ; 
} 
} 

We're on a roll now! We could go on and on, making as complex a strategy as we'd like, making a new 
class for each combination we want. But somewhere around the 439 'th combination, we get mightly tired of 
writing classes. Isn't there an easier way? 

Abstraction is the key here. We want to write code that represents that abstraction of multiple, composite 
strategies. Does what we were doing above depend on the particular concrete strategies that we were using? 
No? Then we should eliminate the concrete classes, raise the abstraction level and use the abstract superclass 
(interface) instead. For a combination of two behaviors, we end up with the following: 

package ballworld; 
import j ava . awt . * ; 

public class MultiStrategy implements IUpdateStrategy { 
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private IUpdate Strategy _sl; 
private IUpdate Strategy _s2; 

public MultiStrategy (IUpdateStrategy si, IUpdateStrategy s2) { 

_sl = si; 

_s2 = s2; 
} 

public void updateState(Ball context) { 

_sl .updateState (context) ; 

_s2.updateState (context) ; 
} 



} 



Notice how we have added a constructor that enables us to initialize the two abstract strategy fields. All we 
have to do is to construct a MultiStrategy object with the two desired strategies, and we're good to go! 

Exercise 2.14 (Solution on p. 35.) 

So if we want three behaviors, all we have to do is to make the same sort of thing but with 3 
abstract strategy fields, right? 

Thus, with just a Mult i strategy we are capable of composing arbitrarily complex behaviors! 

2.3.3.1.3 Composite Patterns 

So what have we wrought here? Let's take a look at the UML diagram of our to most abstract strategies. 
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Figure 2.8: Note that the subclasses hold references to their own superclasses! 



The key to the power that lies in the SwitcherStrategy and the MultiStrategy lies in the fact that 
they hold references to their own superclass, IUpdateStrategy. This is what enables them to be create 
any behavior they want, including combinations of behaviors and dynamic modifications of behaviors. This 
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self-referential class structure is known as the Composite Design Pattern 12 (The Decorator pattern can be 
considered to be specialized form of the Composite pattern). The massive power, flexibility and extensiblility 
that this pattern generates warrants further, more formal study, which is where we're heading next. Stay 
tuned! 



2 http://www. exciton.cs.rice.edu/JavaResources/DesignPatterns/composite. htm 
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Solutions to Exercises in Chapter 2 

Solution to Exercise 2.1 (p. 21) 

No, it won't compile. IBinaryOp is an interface and does not specify any actual executable code, so it 
cannot be instantiated. 
Solution to Exercise 2.2 (p. 21) 

Yes! AddOp is an concrete class and can be instantiated. AddOp is an IBinaryOp (technically, AddOp 
implements the IBinaryOpinterface), so bop can reference it. 
Solution to Exercise 2.3 (p. 21) 

Yes, for the same reasons as the previous exercise! Mult Op is an concrete class and can be instantiated. 
MultOp is an IBinaryOp, so bop can reference it. 
Solution to Exercise 2.4 (p. 21) 

The result is 8 because bop refers to an AddOp instance, whose apply method adds its two input values. 
Solution to Exercise 2.5 (p. 21) 

The result is 15 because bop now refers to an MultOp instance, whose apply method multiplies its two input 
values. 
Solution to Exercise 2.6 (p. 21) 

It is impossible to tell because it depends on the exact type of the object instance to which myOp refers. 
Solution to Exercise 2.7 (p. 21) 

No, because bop is a variable of type IBinaryOp , which is not defined as having a getDescription 
method. This is true even if bop references an object of type MultOp. This is because the static typing 
of bop tells the compiler that it references an IBinaryOp, not the particular concrete type of the object 
it currently references. If we had MultOp mop = new MultOpO, then mop.getDescriptionO is perfectly 
legal. 
Solution to Exercise 2.8 (p. 21) 

Yes, because aop is a variable of type AddOp, and thus can reference an instance of the same type. 
Solution to Exercise 2.9 (p. 21) 

No, because aop is a variable of type AddOp , and Mult I Op is not an AddOp, so aop cannot reference an 
instance of MultOp. 
Solution to Exercise 2.10 (p. 21) 

Yes! bop is a variable of type IBinaryOp, and aop is defined as referencing an AddOp object, which is an 
IBinaryOp . 
Solution to Exercise 2.11 (p. 21) 

Not as written, because bop is a variable of type IBinaryOp (i.e. staticly typed as such), which and does 
not necessarily reference an object of type AddOp. to which aop must reference. That is, a variable of the 
type of the superclas can always reference an object of the type of any subclass, but a variable of the type 
of a particular subclass cannot necessarily reference something of the type of its superclass. Another way 
of saying this is that a superset contains its subsets but not the other way around. The above assignment 
will cause a compile time error because the compiler cannot know if the assignment is possible. An explicit 
cast is required to supress the compile time error (aop = (AddOp) bop), but may trigger a run-time error if 
indeed the instance referred to by bop is not of type AddOp. 
Solution to Exercise 2.12 (p. 31) 

Try it! 
Solution to Exercise 2.13 (p. 31) 

Use the same techniques as before: strategies that hold strategies. 
Solution to Exercise 2.14 (p. 33) 

But isn't a MultiStrategy an IUpdateStrategy iteself? That is, since a MultiStrategy holds 
IUpdateStrategy's, couldn't a MultiStrategy hold a MultiStrategy , which is holding a MultiStrategy 
(or two) which is hold a MultiStrategy , which is holding ? 
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Chapter 3 

Immutable List Structure 

3.1 List Structure and the Composite Design Pattern 1 

3.1.1 Going Shopping 

Before I go to the groceries store, I make a list of what I want to buy. Note how I build my shopping list: I 
start with a blank sheet of paper then I add one item at a time. 

When I get to the store, I start buying things by going down my list. For each item I buy, I mark it off 
the list. 

After I am done shopping, I go to the cashier and check out my items. 

The cashier scans my items one item at a time. Each time, the cash register prints one line showing the 
item just scanned together with its price. Again, note how the cash register builds the list: it start with a 
blank sheet of paper and then add one item at a time. After all items have been scanned, the cashier press 
a key and "poof", the cash register prints a subtotal, then a tax amount for all the taxable items, then a 
total amount, and finally a total number of items bought. 

At different store, the cash register not only prints out all of the above, but also a total amount of 
"savings" due to the fact that I have a "member-plus" card. Some other stores don't care to print the total 
number of items bought at all. Whatever the store, wherever I go, I see "lists" and "list processing" all over. 

The check out cash register uses a program to enter the items and print the receipt. At the heart of 
the program is a container structure to hold data (data structure) and a few algorithms to manipulate the 
structure and the data it holds. The simplest way to organize data is to structure them in a linear fashion; 
that is, intuitively, if we can get hold of one data element, then there is exactly one way to get to the next 
element, if any. We call this linear organization of data the list structure. In order to write program to 
process lists, it is necessary to define what lists are and express their definitions in terms of code. 

3.1.2 What is a list? 

Analogous to the notion of a shape, a list is an abstract notion. Recall how I built my list of groceries items? 
I started with a blank list: an empty list! The empty set! 

An empty list is a list that has no element. 

It is obvious that there are non-empty lists. But what do we mean by a non-empty list? How can we 
articulate such an obvious notion? Consider for example the following list consisting of three elements. 

• milk 

• bread 



lr rhis content is available online at <http://cnx.Org/content/ml5111/l. l/>. 
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• butter 

In the above, we organize the items in a linear fashion with milk being the first element, bread being the next 
element following milk and butter being the next element following bread. Is there any item that follows 
butter? 
Is 

• bread 

• butter 

a list? 
Is 

• butter 

a list? 

Is there a list that follows butter in the above? 

A non-empty list is a list that has an element called first and a list called rest. 

Note that in the above formulation, the rest of a list is itself a list! The definition of a list is an example 
of what we call a recursive definition: the list contains a substructure that is isomorphic to itself. 

3.1.3 List Design and the Composite Design Pattern 

The UML diagram below captures the recursive data definition of the list data structure. 



UML diagram of a list 
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Figure 3.1: A list can be represented using the composite design pattern 



This definition translates into Java code as follows. 



/** * Represents the abstract list structure. */ public interface IList { } 



/** 

* Represents empty lists. 

*/ 

public class MTList implements IList { 

} 



/** 

* Represents non-empty lists. 

*/ 

public class NEList implements IList { 

private Object _first; 

private IList _rest; 

> 
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Table 3.1 

The above is an example of what is called the composite design pattern. The composite pattern is a 
structural pattern that prescribes how to build a container object that is composed of other objects whose 
structures are isomorphic to that of the container itself. In this pattern, the container is called a composite. 
In the above, IList is called the abstract component, MTList is called the basic component and NEList is 
called the composite. The composite design pattern embodies the concept of recursion, one of the most 
powerful thinking tool in computing. (There is a subject in theoretical computer science and mathematics 
called "recursive function theory," which studies the meaning of what computing means and in effect defines 
in the most abstract form what a computer is and what it can and cannot do.) 

3.1.4 List Creation 

Now that we have defined what a list is, we ask ourselves how we can process it? What can we do with a 
list? The above code makes it clear that there is not a whole lot we can do with a list besides instantiating 
a bunch of MTList objects via the call new MTList () (why?). Now that we are using the full Java language, 
we need to write a constructor for NEList in order to instantiate non-empty list objects with appropriate 
first and rest. The Java code for NEList now looks as follows (note how the comments are written). 

/** 

* Represents non-empty lists. 

*/ 

public class NEList implements IList { 

private Object _first; 

private IList _rest; 

/** 

* Initializes this NEList to a given first and a given rest. 

* @param f the first element of this NEList. 

* @param r the rest of this NEList. 
*/ 

public NEList (Object f , IList r) { 

_first = f ; 

_rest = r; 
} 



The list structure as coded in the above is completely encapsulated, that is, all internal components (if 
any) of a list are private and cannot be accessed by any external code. Using the appropriate constructors, 
we can make a bunch of lists to store data but we cannot retrieve data nor do anything with these lists. In 
Object-Oriented Programming (OOP) parlance, the list is said to have no behavior at all. As such they are 
of no use to us. 

3.1.5 List Processing 

In order to perform any meaningful list processing at all, we need to program more "intelligence" into the list 
structure by adding appropriate methods to the list to provide the desired behaviors. So instead of asking 
what we can do with a list, the right question to ask in OOP is "what can a list do for us?" Let us start by 
presenting a few simple tasks that we want a list to perform and try to figure out how an "intelligent" list 
would carry out such tasks via some role acting. 
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3.1.5.1 In class role-acting exercises: 



Compute the length of a list. 

Compute the sum of a list that holds integers. 



3.2 List Structure and the Interpreter Design Pattern 2 

3.2.1 List Processing 

In the previous lecture, we define what a list is and implement it using the composite design pattern. This list 
structure is fully encapsulated and does not expose any of its internal components. In order to manipulate 
such a list without having to make public its internals, we need to add methods to the structure. This lecture 
discusses the structure of the algorithms on the list. 

3.2.1.1 What can a list do? 

3.2.1.1.1 Length of a list 

Suppose we are given a list L and asked to find out how many elements it has. What should we do? The 
temptation here is to start thinking about "traversing" the list and keep a count as we go along, and when 
we encounter the "end" of the list, the count should be the number of elements in the list. But how do we 
know that that's the right answer? In order to determine whether or not the result obtained by counting as 
one traverses the list from beginning to end is correct, we have to define what it means to be the number of 
elements in the list. The number of elements in a list is an abstract notion, isn't it? In order to define such 
a quantity, we need to go back to the definition of what a list is. 

• A list is an abstract notion of a container structure. 

• An empty list is a list that has no element 

• A non-empty list is a list that has an element called first and a list called rest. 

To define the notion of the number of elements in a list, we need to define what we mean by the number of 
elements in an empty list and what we mean by the number of elements in a non-empty list. 



The number of elements in a list is an abstract notion because the list is an abstract notion. 

The number of elements of an empty list is 0. 

The number of elements in a non-empty list that contains first and rest is 1 plus the number of elements 

in rest. 



The definition of the number of elements in a list is thus recursive. The recursive characteristic of this 
definition arises naturally from the recursive characteristic of the list structure. What ever approach we use 
to compute the number of elements in a list, in order to prove correctness, we must show that the result 
satisfies the above definition. 

Here is the code for the above computation. 



2 This content is available online at <http://cnx.org/content/ml5110/!. l/>. 
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package listFW; /** * Represents the abstract list structure. */ public interface 
IList { /** * Abstract notion of the number of elements in this IList. */ public int 
get Length (); } 



package listFW; 
/** 
* Represents empty lists. 
*/ 
public class MTList implements IList { 
/** 
* The number of elements in an empty 1: 

*/ 

public int getLengthO { 

return 0; 
> 
> 



package listFW; 
/** 
* Represents non-empty lists. 
*/ 
public class NEList implements IList { 

private Object _first; 
st iprirearbe IList _rest; 

// Constructor ommitted. 

/** 

* The number of elements in a non-empty 

* the number of elements of its rest pli 

*/ 

public int getLengthO { 

return 1 + _rest. getLengthO ; 
} 



list is 
1. 



ILS 



continued on next page 
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Table 3.2 

The above coding pattern is an example of what is called the interpreter design pattern: we are inter- 
preting the abstract behavior of a class (or interface) in each of the concrete subclasses (or implementations). 
The composite pattern is a pattern to express the structure of a system, while the interpreter pattern is used 
to express the behaviors (i.e. methods) of the system. The interpreter pattern is usually applied to coding 
methods in a composite structure. In a later lecture, we shall see another way of expressing the behavior of 
a composite structure without having to add new methods and interpret them. 

3.2.1.2 Code Template 

Whenever we want the IList to perform a task, we add a method to IList and write appropriate concrete 
implementations in MTList and NEList. The following table illustrates the code template for writing the 
concrete code in MTList and NEList. 



interface IList 



public abstract returnType met hodName (parameter list); // returnType may be 'void' 



MTList 
// no data 



public returnType methodName (parameter list) 

/* 

This is in general the base case of a recur 

Write the (non-recursive) code to solve the 

*/ 

} 



NEList 

Object _first; 
IList _rest; 



public returnType methodName (parameter list) 

/* 

il7teis:ai§..in general a recursive method. 
pTbfelemde here can refer to _first and _rest, 

When referencing _rest, one usually makes the 

_rest. methodName (appropriate parameters) . 

*/ 

} 



continued on next page 
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Table 3.3 



3.2.1.2.1 In Class Exercises (Role-Acting) 



• Find a number in a list and return "Found it!" if the number is in the list otherwise return "Not found!" 

• Append a list B to a given list A and return a new list consisting of A and B concatenated together. 



3.3 Visitor Design Pattern 3 

3.3.1 1. Decoupling Algorithms from Data Structures 

Recall the current formulation of the immutable list structure using the composite pattern. 



3 This content is available online at <http://cnx.org/content/ml6707/!. l/>. 
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Figure 3.2 



Each time we want to compute something new, we apply the interpreter pattern add appropriate methods 
to IList and implement those methods in MTList and NEList. This process of extending the capability of 
the list structure is error-prone at best and cannot be carried out if one does not own the source code for this 
structure. Any method added to the system can access the private fields of MTList and NEList and modify 
them at will. In particular, the code can change _fist and _rest of NEList breaking the invariant immutable 
property the system is supposed to represent. The system so designed is inherently fragile, cumbersome, 
rigid, and limited. We end up with a forever changing IList that includes a multitude of unrelated methods. 

These design flaws come of the lack of delineation between the intrinsic and primitive behavior of the 
structure itself and the more complex behavior needed for a specific application. The failure to decouple 
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primitive and non-primitive operations also causes reusability and extensibility problems. The weakness 
in bundling a data structure with a predefined set of operations is that it presents a static non-extensible 
interface to the client that cannot handle unforeseen future requirements. Reusability and extensibility 
are more than just aesthetic issues; in the real world, they are driven by powerful practical and economic 
considerations. Computer science students should be conditioned to design code with the knowledge that it 
will be modified many times. In particular is the need for the ability to add features after the software has 
been delivered. Therefore one must seek to decouple the data structures from the algorithms (or operations) 
that manipulate it. Before we present an object-oriented approach to address this issue, let's first eat! 

3.3.2 2. To Cook or Not To Cook 

Mary is a vegetarian. She only cooks and eats vegetarian food. John is carnivorous. He cooks and eats 
meat! If Mary wants to eat broccoli and cheese, she can learn how to cook broccoli and cheese. If she 
wants corn of the cob, she can learn how to cook corn on the cob. The same goes for John. If he wants to 
eat greasy hamburger, he can learn how to cook greasy hamburger. If he wants to eat fatty hotdog, he can 
learn how to cook fatty hotdog. Every time John and Mary want to eat something new, they can learn how 
to cook it. This requires that John and Mary to each have a very big head in order to learn all the recipes. 

But wait, there are people out there called chefs! These are very special kinds of chefs catering only 
to vegetarians and carnivores. These chefs only know how to cook two dishes: one vegetarian dish and 
one meat dish. All John and Mary have to do is to know how to ask such a chef to cook their favorite 
dish. Mary will only order the vegetarian dish, while John will only order the meat dish! 

How do we model the vegetarian, the carnivore, the chef, the two kinds of dishes the chef cooks, and how 
the customer orders the appropriate kind of dish from the chef? 

3.3.2.1 The Food 

To simplify the problem, let's treat food as String. (In a more sophisticated setting, we may want to 
model food as some interface with veggie and meat as sub-interface.) 

3.3.2.2 The Food Consumers 

Vegetarians and carnivores are basically the same animals. They have the basic ingredients such as salt and 
pepper to cook food. They differ in the kind of raw materials they stock to cook their foods and in the way 
they order food from a chef. Vegetarians and Carnivores can provide the materials to cook but do not know 
how to cook! In order to get any cooked meal, they have to ask a chef to cook for them. We model them as 
two concrete subclasses of an abstract class called AEater. AEater has two concrete methods, getSalt and 
getPepper, and an abstract method called order, as shown in the table below. 



public abstract class AEater { public String getSaltO { return "salt"; } public String 
getPepper () { return "pepper"; } /** * Orders n portions of appropriate food from 
restaurant r. */ public abstract String order(IChef r, Integer n) ; // NO CODE BODY! 
} 



continued on next page 
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public class Vegetarian extends AEater{ 


public class Carnivore extends AEater{ 


public String getBroccoliO { 




public String getMeatO { 


return "broccoli"; 




return "steak"; 


> 




} 


public String getCornO { 




public String getChickenO { 


return "corn"; 




return "cornish hen"; 


> 




} 


public String order (IChef c, Object n) - 


■ 


public String getDogO { 


// code to be discussed later; 




return "polish sausage"; 


> 




> 


> 




public String order (IChef c, Object n) ^ 




// 
} 


code to be discussed later; 
> 



Table 3.4 



3.3.2.3 The Chef 

The chef is represented as an interface IChef with two methods, one to cook a vegetarian dish and one to 
cook a meat dish, as shown in the table below. 



interface IChef { String cookVeggie (Vegetarian h, Integer n) ; String cookMeat (Carnivore 
h, Integer n) ; } 



public class ChefWong implements IChef { 

public static final ChefWong Singleton 

= new ChefWong () ; 

private ChefWong () {} 

public String cookVeggie (Vegetarian h, Inte| 

return n + " portion(s) of " + 

h. get Carrot () + ", " + 

h. get Salt () ; 

} 

public String cookMeat (Carnivore h, Integer 

return n + " portion(s) of " + 

h. getMeatO + ", " + 

h.getPepperO ; 

> 
> 



public class ChefZung implements IChef { 

public static final ChefZung Singleton 

= new Chef ZungO ; 

private ChefZung () {} 
;epiihjii String cookVeggie (Vegetarian h, Intej 

return n + " portion (s) of " + 

h.getCornO + ", " + 

h. get Salt () ; 

} 
njhilflic String cookMeat (Carnivore h, Integer 

return n + " portion (s) of " + 

h.getChickenO + ", " + 

h.getPepperO + 

", " + h.getSaltO; 

} 

} 



er n) { 



n) { 



Table 3.5 
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3.3.2.4 Ordering Food From The Chef 

To order food from an IChef , a Vegetarian object simply calls cookVeggie, passing itself as one of the pa- 
rameters, while a Carnivore object would call cookMeat, passing itself as one of the parameters as well. The 
Vegetarian and Carnivore objects only deal with the IChef object at the highest level of abstraction and do 
not care what the concrete IChef is. The polymorphism machinery guarantees that the correct method in 
the concrete IChef will be called and the appropriate kind of food will be returned to the AEater caller The 
table below shows the code for Vegetarian and Carnivore, and sample client code using these classes. 



public class Vegetarian extends AEater { 

// other methods elided 

public String order (IChef c, int n) { 

return c. cookVeggie (this, n) ; 

} 

} 



public class Carnivore extends AEater { 

// other methods elided 

public String order (IChef c, int n) { 

return c. cookMeat (this, n) ; 

} 

} 



// client code public void party (AEater e, IChef c, int n) { System. out .println (e. order ( 
n));} // blah blah blah... AEater John = new CarnivoreO; AEater Mary = new 
Vegetarian () ; party(Mary, Chef Wong. Singleton, 2); party (John, Chef Zung. Singleton, 1); 



Table 3.6 



The above design is an example of what is called the visitor pattern. 

• The abstract class AEater and its concrete subclasses are called the hosts. The method public String 
order(IChef c, Object n) is called the hook method. Each concrete subclasses of AEater knows exactly 
to call the appropriate method on the IChef parameter, but does know and need not how the IChef 
concretely perforns its task. This allows an open-ended number of ways to cook the appropriate kinds 
of food. 

• The chef interface IChef and all of its concrete implementations are called visitors. When an IChef 
performs cookMeat /cookVeggie, it knows that its host is a Carnivore/Vegetarian and can only call the 
methods of Carnivore/Vegetarian to cook a dish. Java static type checking will flag an error should 
there be a call on the host to getCarot in the method cookMeat. This is makes the interaction between 
hosts (Vegetarian and Carnivore) and visitors (IChef and all of its concrete implementations) much 
more robust. 



3.3.3 3. The Visitor Pattern 

The visitor pattern 4 is a pattern for communication and collaboration between two union patterns: a "host" 
union and a "visitor" union. An abstract visitor is usually defined as an interface in Java. It has a 
separate method for each of the concrete variant of the host union. The abstract host has a method (called 
the "hook") to "accept" a visitor and leaves it up to each of its concrete variants to call the appropriate 
visitor method. This "decoupling" of the host's structural behaviors from the extrinsic algorithms on the 
host permits the addition of infinitely many external algorithms without changing any of the host union 



4 http://www.exciton.es. rice.edu/JavaResources/DesignPatterns/ VisitorPattern.htm 
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code. This extensibility only works if the taxonomy of the host union is stable and does not change. If we 
have to modify the host union, then we will have to modify ALL visitors as well! 
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return 


v.visitHostN (this, input); 


h 




return 1 


/.visitHost2 (this, input); 


h 



HostN 



Object : accept(I Visitor v, Object input) 



Host2 



+ Object : accept(I Visitor v, Object input) 



return v.visitHostl (this, input); 



^ 



Hostl 



+ Object : accept(I Visitor v, Object input) 
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Figure 3.3 
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NOTE: All the "state-less" visitors, that is visitors that contain no non-static fields should be single- 
tons. Visitors that contain non-static fields should not be singletons. 

3.3.4 4. Fundamental Object-Oriented Design Methodology (FOODM) 

1. Identify and separate the variant and the invariant behaviors. 

2. Encapsulate the invariant behaviors into a system of classes. 

3. Add "hooks" to this class to define communication protocols with other classes. 

4. Encapsulate the variant behaviors into a union of classes that comply with the above 
protocols. 

The result is a flexible system of co-operating objects that is not only reusable and extensible, but also easy 
to understand and maintain. 

Let us illustrate the above process by applying it to the design of the immutable list structure and its 
algorithms. 

1. Here, the invariant is the intrinsic and primitive behavior of the list structure, IList, and the variants 
are the multitude of extrinsic and non-primitive algorithms that manipulate it, IListAlgo. 

2. The recursive list structure is implemented using the composite design pattern and encapsulated with 
a minimal and complete set of primitive structural operations: getFirstO and getRest(). 

3. The hook method Object execute (IListAlgo ago, Object inp) defines the protocols for operat- 
ing on the list structure. The hook works as if a IList announces to the outside world the following 
protocol: If you want me to execute your algorithm, encapsulate it into an object of type IListAlgo, 
hand it to me together with its inp object as parameters for my executeQ. I will send your algorithm 
object the appropriate message for it to perform its task, and return you the result. 

• emptyCase (...) should be the part of the algorithm that deals with the case where I am empty. 

• nonEmptyCase( . . . ) should be the part of the algorithm that deals with the case where I am not 
empty." 

4. IListAlgo and all of its concrete implementations forms a union of algorithms classes that can be sent 
to the list structure for execution. 

Below is the UML class diagram of the resulting list design. Click here to see the full documentation. 5 
Click here to see the code 6 . 



5 http://www. owlnet.rice.edu/~comp201/08-spring/lectures/visitor/listFW/doc/ 
6 http://www. owlnet.rice.edu/~comp201/08-spring/lectures/lecl7/listFW. zip 
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Figure 3.4 



The above design is nothing but a special case of the Visitor Pattern. The interface IList is called 
the host and its method execute () is called a "hook" to the IListAlgovisitors. Via polymorphism, 
IList knows exactly what method to call on the specific IListAigo visitor. This design turns the list 
structure into a (miniature) framework where control is inverted: one hands an algorithm to the structure to 
be executed instead of handing a structure to an algorithm to perform a computation. Since an IListAigo 
only interacts with the list on which it operates via the list's public interface, the list structure is capable of 
carrying out any conforming algorithm, past, present, or future. This is how reusability and extensibility is 
achieved. 



3.3.5 5. List Visitor Examples 
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/** * Computes the length of the IList host. */ public class GetLength implements 
IListAlgo { /** * Singleton Pattern. */ public static final GetLength Singleton = new 
GetLength () ; private GetLength () { } 



/** 

* Returns Integer (0). 

* @param nu not used 

* ©return Integer (0) 
*/ 

public Object emptyCase(MTList host, Object 
return 0; 

> 



/** 

* Return the length of the host's rest plus 

* @param nu not used. 

* ©return Integer > 0. 
*/ 

.public {Object nonEmptyCase(NEList host, Object. 
Object restLen = host .getRestO .execute (thi^) ; 
return 1 + (Integer) restLen) ; 
} 



nu) { 



Table 3.7 



package listFW; /** * Computes a String reprsentation of IList showing a left 
parenthesis followed * by elements of the IList separated by commas, ending with with 
a right parenthesis. * ©stereotype visitor */ public class ToStringAlgo implements 
IListAlgo { public static final ToStringAlgo Singleton = new ToStringAlgo () ; private 
ToStringAlgo () { } 



/** 

* Returns "()". 

*/ 
public Object emptyCase(MTList host, Object 
return "()"; 
} 



/** 

* Passes "(" + first to the rest of IList ind asks for he 

*/ 
.pulihpc) Sbject nonEmptyCase(NEList host, 0bj« 
return host . getRest ( ) . execute (ToStr ingHelper . 

> 
> 



ct . . . ~inp) { 
.Singleton, " ( 



Table 3.8 
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/** * Helps ToStringAlgo compute the String representation of the rest of the list. 
*/ class ToStringHelper implements IListAlgo { public static final ToStringHelper 
Singleton = new ToStringHelper () ; private ToStringHelper () { } 



/** 

~* Returns the accumulated String + ")"• 

~* At end of list: done! 

-*/ 

public Object emptyCase(MTList host, Object 

return" acc[0] + ")"; 

> 



/** 

* Continues accumulating the String representation by apj 

* and recurse! 
*/ 

.pubird Sbject nonEmptyCase(NEList host, 0bj€ 
return host .getRest() .execute (this, acc[0] ^ 
} 
} 



ct . . . ace) { 
", " + host. | 



Table 3.9 

We now can use to ToStringAlgo to implement the toStringQ method of an IList. 
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package listFW; 

public class MTList implements IList { 



MTL 



parcLmptETat€ 



/** 

* Singleton Pattern 

*/ 

public final static MTList Singleton = new 

private MTList () { } 

/** 

* Calls the empty case of the algorithm al 

* passing to it itself as the host parameter 

* and the given input inp as the input 

* This method is marked as final to prevent; 

* subclasses from overriding it. 

* Finalizing a method also allows the comp: 

* generate more efficient calling code. 

*/ 

public final Object execute ( IList Algo algo, 
return algo. emptyCase (this, inp); 

} 

public String toStringO { 
return (String) ToStr ingAlgo . Singleton . emptlyC 

> 



package listFW; 



public class NEList implements IList { 
/** 

* The first data element. 

*/ 
private Object _first; 

ist(); 
/** 

* The rest or "tail" of this NEList. 
o, * Data Invariant: _rest != null; 

*/ 

e IList _rest; 
all 

/** 
ler to* Initializes this NEList to a given 

* @param f the first element of this 

* @param r != null, the rest of this 
Object/ . . inp) { 

public NEList (Object f , IList r) { 
_first = f ; 
_rest = r; 
asejthis) ; 



f irst 



NEL 
NEL 



/** 



prevent 



* Returns the first data element of thi 

* This method is marked as final to 

* from overriding it . 

* Finalizing a method also allows the Compiler to gei 

* more efficient calling code. 
*/ 

public final Object getFirstO { 
return _first; 

> 



/** 



prevent 



* Returns the first data element of thi. 

* This method is marked as final to 

* subclasses from overriding it. 

* Finalizing a method also allows the Compiler 

* to generate more efficient calling code 
*/ 

public final IList getRestO { 

return _rest ; 
} 



IListAlgo pare 
liost parameter 



/** 

* Calls the nonEmptyCase method of the 

* passing to the method itself as the 

* given input as the input parameter. 

* This method is marked as final to 

* overriding it. Finalizing a method 

* to generate more efficient calling ccjde. 
*/ 

public final Object execute (IListAlgo algo, Object... 
return algo. nonEmptvCase (this , inp) 



and a give 
ist . 
ist . 



s NEList. 

all subc] 



s NEList. 
all 



prevent 
a]. so 



all subc] 
allows the 
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Table 3.10 

Download the above code here 7 . 

3.4 Abstract Factory Design Pattern 8 

3.4.1 1. Information Hiding 

Information hiding is a tried-and-true design principle that advocates hiding all implementation details of 
software components from the user in order to facilitate code maintenance. It was first formulated by David 
L. Parnas (in 1971-1972) as follows. 

• One must provide the intended user with all the information needed to use the module correctly and 
nothing more. 

• translation to OOP: the user should not know anything about how an interface or abstract class 
is implemented. For example, the user need not and should not know how IList is implemented 
in order to use it. The user should only program to the abstract specification. 

• One must provide the implementor with all the information needed to complete the module and nothing 
more. 

• translation to OOP: the implementor of a class or an interface should not know anything about 
how it will be used. For example, the implementor need not and should not know how, when, or 
where IList will be used. The implementor should write the implementation code based solely 
on the abstract specification. 

By adhering to the above, code written by both users and implementors will have a high degree of flexibility, 
extensibility, interoperability and interchangeability. 

The list framework that we have developed so far has failed to hide MTList and NEList, which are concrete 
implementations of IList, the abstract specification of the list structure. In many of the list algorithms that 
we have developed so far, we need to call on MTList .Singleton or the constructor of NEList to instantiate 
concrete IList objects. The following is another such examples. 



7 http://www. owlnet.rice.edu/~comp201/08-spring/lectures/lecl7/listFW. zip 
8 This content is available online at <http://cnx.org/content/ml6796/!. l/>. 
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Insert InOrder . j ava 



import listFW.*; 

/** 

* Inserts an Integer into an ordered host list, assuming the host list contains 

* only Integer objects. 
*/ 

public class InsertlnOrder implements IListAlgo { 

public static final InsertlnOrder Singleton = new InsertlnOrder () ; 
private InsertlnOrder () { 

> 

/** 

* This is easy, don't you think? 

* @param inp inp[0] is an Integer to be inserted in order into host. 

*/ 

public Object emptyCase(MTList host, Object... inp) { 

return new NEList (inp[0] , host); 
} 

/** 

* Delegate (to recur) ! 

* @param inp inp[0] is an Integer to be inserted in order into host. 
*/ 

public Object nonEmptyCase (NEList host, Object... inp) { 
int n = (Integer) inp [0] ; 
int f = (Integer)host .getFirst () ; 
return n < f ? 

new NEList (inp [0] , host) : 

new NEList (host .getFirst () , (IList)host .getRest() .execute (this, inp[0])) 
} 



Table 3.11 

The above algorithm to insert in order an integer into an ordered list of integers can only be used for a very 
specific implementation of IList, namely the one that has MTList and NEList as concrete subclasses. How 
can we write list algorithms that can be used for ANY implementation of the abstract specification of the 
list structure represented by the abstract class IList? 

We can achieve our goal by 

1. abstracting the behavior of MTList and NEList into interfaces with pure abstract structural behaviors. 

2. applying the Abstract Factory Design Pattern 9 to hide the concrete implementation from the user. 



9 http://www. exciton.cs.rice.edu/JavaResources/DesignPatterns/FactoryPattern. htm 
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3.4.2 2. Abstract List Behaviors 

The concrete empty list and non-empty list implemented as MTList and NEList are now expressed as 
interfaces as follow. 



package listFW; /** * Represents the abstract behavior of the immutable list structure. 
* A list intrinsically "knows" how to execute an algorithm on itself. */ interface 
IList { Object execute (IListAlgo algo, Object... inp) ; } 



package listFW; 

/** 

* Represents the immutable empty list. 

* The empty list has no well-defined 

* it has no first and no rest. 

*/ 

interface IMTList extends IList { 
> 



s t r u c t ; ur fclAib ehiannrbarb 1 e 



package listFW; 



/** 



* Represents the immutable non-empty list 
non-empty list has a data 

* isomorphic subcomponent called rest . It 

* provides access to its internal data (fi 
*/ 

interface INEList extends IList { 
/** 

* "Gettor" method for the list's first 

* ©return this INElist's first element 
*/ 

Object getFirstO; 

/** 

* "Gettor" method for the list's rest. 

* ©return this INElist's rest. 
*/ 

IList getRestQ; 



obj 



irst 



iect called f] 
structural be 
) and substi 



Table 3.12 



3.4.3 3. Abstract List Factory 

Before we describe in general what the Abstract Factory Pattern is, let's examine what we have to do 
in the case of IList. 



• Define an abstract factory interface, IListFactory, to manufacture empty and non-empty IList 
objects. Put IList, IMTList, INEList, IListVistor, and IListFactory in the same pack- 
age. IListFactory is specified as followed. 
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IListFactory . j ava 



package listFW; 

/** 
* Abstract factory to manufacture IMTList and INEList. 

*/ 

interface IListFactory { 
/** 

* Creates an empty list. 

* ©return an IMTList object. 
*/ 

IMTList makeEmptyList () ; 

/** 

* Creates a non-empty list containing a given first and a given rest. 

* @param first a data object. 

* @param rest != null, the rest of the non-empty list to be manufactured. 

* ©return an INEList object containing first and rest 

* ©exception IllegalArgumentException if rest is null. 
*/ 

INEList makeNELi st (Object first, IList rest); 



Table 3.13 

IList, IListAlgo, and IListFactory prescribe a minimal and complete abstract specification of what 
we call a list software component. We claim without proof that we can do everything we ever want to 
do with the list structure using this specification. 

• All algorithms (i.e. visitors) that call for the creation of concrete IList objects will need to have an 
abstract factory as a parameter and use it to manufacture IList objects. We usually pass the factory 
as an argument to the constructor of the visitor. The visitor is thus not a singleton. 
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Insert InOrderWithFactory . j ava 



import listFW.*; 

/** 

* Inserts an Integer into an ordered host list, assuming the host list contains 

* only Integer objects. Has no knowledge of how IList is implemented. Must 

* make use of a list factory (IListFactory) to create IList objects instead of 

* calling the constructors of concrete subclasses directly. 
*/ 

public class InsertlnOrderWithFactory implements IListAlgo { 

private IListFactory _listFact; 

public InsertInOrderWithFactory(IListFactory If) { 

_listFact = If; 
} 

/** 

* Simply makes a new non-empty list with the given inp parameter as first. 

* @param host an empty IList . 

* @param inp inp[0] is an Integer to be inserted in order into host. 
*/ 

public Object emptyCase(IMTList host, Object... inp) { 

return _listFact .makeNEList (inp[0] , host); 
} 

/** 

* Recur! 

* @param host a non-empty IList. 

* @param inp inp[0] is an Integer to be inserted in order into host. 
*/ 

public Object nonEmptyCase(INEList host, Object... inp) { 
int n = (Integer) inp [0] ; 
int f = (Integer)host .getFirst () ; 
return n < f ? 

_listFact .makeNEList (inp [0] , host) : 
_listFact .makeNEList (host .getFirst () , 

(IList)host . getRest () .execute (this, inp[0] ) ) ; 
} 



Table 3.14 



The above algorithm only "talks" to the list structure it operates on at the highest level of abstraction 
specified by IList and IListFactory. It does know and does not care how IList and IListFactory are 
implemented. Yet it can be proved to be correct. This algorithm can be plugged into any system that 
subscribes to the abstract specification prescribed by IList, IListAlgo, and IListFactory. 
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• Provide a concrete implementation of the abstract factory that contains all concrete subclasses of IList 
as private static classes and thus hide them from all external code. 
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CompositeListFactory . j ava 



package listFW. factory; 
import listFW.*; 

/** 

* Manufactures concrete IMTList and INEList objects. Has only one 

* instance referenced by CompositeListFactory .Singleton. 

* MTList and NEList are static nested classes and hidden from all external 

* client code. The implementations for MTList and NEList are the same as 

* before but completely invisible to the outside of this factory. 
*/ 

public class CompositeListFactory implements IListFactory { 

/** 

* Note the use of private static. 

*/ 

private static class MTList implements IMTList { 

public final static MTList Singleton = new MTList () ; 

private MTList () { 

} 

final public Object execute (IListAlgo algo, Object... inp) { 

return algo. emptyCase (this, inp); 
} 

public String toStringO { 

return "()"; 
} 
} 

/** 

* Note the use of private static. 
*/ 

private static class NEList implements INEList { 
private Object _first; 
private IList _rest; 

public NEList (Object dat , IList rest) { 

_first = dat; 

_rest = rest; 
} 

final public Object getFirstO { 
return _first; 

> 

final public IList getRestO { 
return _rest ; 

> 

final public Object execute (IListAlgo algo, Object... inp) { 

return algo. nonEmptyCase (this, inp); 
> 
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Table 3.15 

• Pass such a concrete factory to all client code that need to make use of the abstract factory to manu- 
facture concrete IList instances. 

Below is an example of a unit test for the Insert InOrderWithFactory algorithm. 



Test_InsertInOrderWithFactory . j ava 



package listFW. visitor .test ; 
import listFW.*; 
import listFW.f actory . * ; 
import listFW. visitor .* ; 

import j unit . framework . TestCase ; 

/** 

* A JUnit test case class. 

* Every method starting with the word "test" will be called when running 

* the test with JUnit . 
*/ 

public class Test_InsertInOrderWithFactory extends TestCase { 



public void test_ordered_insert () { 

IListFactory fac = CompositeListFactory .Singleton; 
IListAlgo algo = new Insert InOrderWithFactory (f ac) ; 

IList listO = f ac.makeEmptyList () ; 

assertEquals( "Empty list", "()", listO.toStringO) ; 

IList listl = (IList) listO. execute (algo, 55); 
assertEquals("55->0", "(55)", listl .toStringO) ; 

IList list2 = (IList) listl .execute (algo, 30); 
assertEquals("30->(55)", "(30, 55)", list2.toString() ) ; 

IList list3 = (IList) list2. execute (algo, 100); 

assertEquals("100 -> (30, 55)", "(30, 55, 100)", list3.toString() ) ; 

IList list4 = (IList) list3. execute (algo, 45); 

assertEquals("45->(30, 55, 100)", "(30, 45, 55, 100)", list4.toString()) ; 

IList list5 = (IList) list4. execute (algo, 60); 

assertEquals("60 -> (30, 45, 55, 100)", "(30, 45, 55, 60, 100)", list5.toString()) ; 
} 
} 



Table 3.16 



64 CHAPTER 3. IMMUTABLE LIST STRUCTURE 

The above design process is an example of what is called the Abstract Factory Design Pattern. The 
intent of this pattern is to provide an abstract specification for manufacturing a family of related objects 
(for examples, the empty and non-empty IList) without specifying their actual concrete classes thus hiding 
all details of implementation from the user. 

Our example of the list structure framework successfully delineates specification from implementation 
and faithfully adheres to the principle of information hiding. 

• IList, IMTList, INEList, IListAlgo, and IListFactory provide a minimal and complete abstract 
specification. 

• Insert InOrderWithFactory is a concrete implementation of IListAlgo that performs a concrete 
operation on the host list. Yet this algorithm need only communicate with the list structure and the list 
factory via their public interface. It will work with any implementation of IList and IListFactory. 

• CompositeListFactory is a concrete implementation of IListFactory. It uses the composite pattern 
and the visitor pattern to implement IList. It only communicates with IListAlgo at and knows 
nothing about any of its concrete implementation. The private static attributes provide the proper 
mechanism to hide all implementation details from all code external to the class. 

Click here to access the complete javadoc documentation and UML class diagram of the list component 10 
described in the above. 

Click here to download the complete source code and documentation of the list component 11 described 
in the above. 

3.4.4 4. Frameworks 

The following is a direct quote from the Design Patterns book by Gamma, Helm, Johnson, and Vlissides 
(the Gang of Four - GoF). 

"Frameworks thus emphasizes design reuse over code resuse... Reuse on this level leads to an inversion 
of control between the application and the software on which it's based. When you use a toolkit (or a 
conventional subroutine library software for that matter), you write the main body of the application and 
call the code you want to reuse. When you use a framework, you reuse the main body and write the code it 
calls...." 

The linear recursive structure (IList) coupled with the visitors as shown in the above is one of the 
simplest, non-trivial, and practical examples of frameworks. It has the characteristic of "inversion of 
control" described in the quote. It illustrates the so-called Hollywood Programming Principle: Don't call 
me, I will call you. Imagine the IList union sitting in a library. 

The above list framework dictates the design of all algorithms operating on the list structure: 

• All algorithms must be some concrete implementation of IListAlgo. 

• Algorithms that require the construction of empty and/or non-empty lists, must do so via some 
abstract list factory, IListFactory. 

• In order to apply an algorithm to a list, one must ask a list to "execute" that algorithm, giving it the 
required input parameter. 

When we write an algorithm on an IList in conformance with its visitor interface, we are writing code 
for the IList to call and not the other way around. By adhering to the IList framework's protocol, all 
algorithms on the IList can be developed much more quickly. And because they all have similar structures, 



10 http://cnx.org/content/ml6796/latest/me:///C:%5CUsers%5Cdxnguyen.ADRICE%5CDocuments%5CMy%20Web%20Sites%5CRice%5Ccon 
spring%5Clectures%5Clec20%5ClistFW%5Cdoc%5C 

n http://cnx.org/content/ml6796/latest/me:///C:%5CUsers%5Cdxnguyen.ADRICE%5CDocuments%5CMy%20Web%20Sites%5CRice%5Ccon 
spring%5Cds%5ClistFW.zip 
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they are much easier to "maintain". The IList framework puts polymorphism to use in a very effective 
(and elegant!) way to reduce flow control and code complexity. 

We do not know anything about how the above list framework is implemented, yet we have been able to 
write quite a few algorithms and test them for correctness. In order to obtain concrete lists and test an 
algorithm, we call on a concrete IListFactory, called CompositeListFactory, to manufacture empty and 
non-empty lists. We do not know how this factory creates those list objects, but we trust that it does the 
right thing and produces the appropriate list objects for us to use. And so far, it seems like it's doing its 
job, giving us all the lists we need. 



3.4.5 5. Bootstrapping Along 

Let's take a look back at what we've done with a list so far: 

1. Created an invariant list interface with two variant concrete subclasses (Composite pattern) where 
any algorithms on the list where implemented as methods of the interface and subclasses (Interpreter 
pattern) 

2. Extracted the variant algorithms as visitors leaving behind an invariant "execute" method. Accessor 
methods for first and rest installed. The entire list structure now becomes invariant. 

3. Abstracted the creation of a list into an invariant factory interface with variant concrete subclass 
factories. 

4. Separated the list framework into an invariant hierarchy of interfaces and a variant implementation 
which was hidden inside of a variant factory class. 

Is there something systematic going on here? 

Notice that at every stage in our development of our current list framework, we have applied the same 
abstraction principles to the then current system to advance it to the next stage. Specifically, we have 
identified and separated the variant and invariant pieces of the system and defined abstract representations 
whenever needed. 

This really tells us about some general characteristics of software development: 

• Software development is an iterative process. You never get the right answer the first time and you 
have to slowly "evolve" your code closer and closer to what you want. 

• Every time you change your code you learn something more and/or new about your system and/or 
problem. This is because every new formulation of your solution represents a new way, a new view as 
it were, on the problem and this new view highlights aspects you hadn't considered before. 

• The revision process is driven along by a repetitive application of the abstract decomposition techniques 
such as separating the variant and invariant. 

Are we done with our list refinements? Will we ever be "done"? What do the above characteristics say 
about the way we should approach software development? 

Also, now that we have managed to abstract structure, behavior and construction, is there anything left 
to abstract? Or is there one more piece to our abstraction puzzle (at least)? 

3.5 Inner Classes 12 

3.5.1 1. Helpers are the Variants 

Consider again the familiar problem of computing a String representation of an IList that displays a 
comma-separated list of its elements delimited by a pair of matching parentheses. We have seen at least one 
way to compute such a String representation using a visitor called ToStringAlgo. Below are three different 
algorithms, ToStringl, ToString2 and ToString3, that compute the same String representation. 



2 This content is available online at <http://cnx.org/content/ml7220/!. l/>. 
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Main Visitor ToStringl 



package listFW. visitor ; 

import listFW.*; 

public class ToStringl implements IListAlgo 

public static final ToStringl Singleton = n< 

private ToStringl () { 
} 

public Object emptyCase(IMTList host, Object 

return "()"; 

} 

public Object nonEmptyCase(INEList host, Ob" 

return host .getRest () . execute (ToStringlHelp. 

"(" + host.getFirstO) ; 

} 

} 



Tail-recursive helper ToStringlHelp 



/** 



* Helps ToStringl compute the String 
{ * It takes as input the accumulated strin, 
w foEtsHngltms accumulated string contains 

* the elements of the preceding list, each 

*/ 

class ToStringlHelp implements IListAlgo { 
public static final ToStringlHelp Singleton 
.. nu) { 

private ToStringlHelp () { 
} 



representat 



ion of tl 

representatioi 

tthe left most j 

separated by i 



eptoblicnBLftjict emptyCase(IMTList host, Object... ace) { 
SiagilBitEoaccEO] + ")"; 
} 



public Object nonEmptyCase(INEList host, 0b~ 

return host .getRest () .execute (this, acc[0] 

+ host.getFirstO); 

} 

} 



continued on next page 



= new ToStrin^ 



ect . . . ace) { 
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Table 3.17 



Main Visitor ToString2 



package listFW. visitor ; 
import listFW.*; 



public class ToString2 implements IListAlgo 
public static final ToString2 Singleton 

private ToString2() { 
} 

public Object emptyCase(IMTList host, Object 

return "()"; 

} 

public Object nonEmptyCase(INEList host, Ob; 

return host .getRest () . execute (ToString2Help. 

host .getFirst() .toStringO) ; 

} 

} 



/** 
* Helps ToString2 compute the String representation of tl 
*/ 
{class ToString2Help implements IListAlgo { 
= n^wpuloE±ariag£l($c. final ToString2Help Singleton 



Tail-recursive helper ToString2Help 



private ToString2Help() { 
} 

.pub hid Sbject emptyCase(IMTList host, Object 
return "(" + acc[0] + ")"; 
} 

eptoblicnBLftjict nonEmptyCase(INEList host, Ob; 
SiegiEitEohQst . getRest () .execute (this, 

acc[0] + ", " + host.getFirstO) ; 

} 

} 



continued on next page 



= new ToStrin^ 



ace) { 



ect . . . ace) { 
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Table 3.18 



Main Visitor ToString3 



package listFW. visitor ; 
import listFW.*; 



public class ToString3 implements IListAlgo 
public static final ToString3 Singleton 

private ToString3() { 
} 

public Object emptyCase(IMTList host, Object 

return "()"; 

} 

public Object nonEmptyCase(INEList host, Ob; 

return "(" + host .getFirst () 

+ host . getRest () . execute (ToString3Help . Sin, 

> 
> 



/** 

* Helps ToString3 compute the String representation of tl 

*/ 

{class ToString3Help implements IListAlgo { 
= n^wpuloE±ariag«Bl($c. final ToString3Help Singleton 



Non tail-recursive helper ToString3Help 



= new ToStrin^ 



private ToString3Help() { 
} 

.pubhiid Sbject emptyCase(IMTList host, Object... nu) { 
return ")"; 
} 

eptoblicnBLftjict nonEmptyCase(INEList host, Object... nu) { 
return ", " + host .getFirst () 
oh^^t .getRest () .execute (this) ; 

> 
> 



gle* 



continued on next page 
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Table 3.19 

What makes each of the above different from one another is its helper visitor. Each helper defined in 
the above will only perform correctly if it is passed the appropriate parameter. In a sense, each helper is an 
implementation of the main visitor. We should hide each of them inside of its corresponding main visitor to 
ensure proper usage and achieve full encapsulation of the main visitor. 

3.5.2 2. Hiding Helpers 

The most secure way to hide the helper visitor is to move it inside of the main visitor and make it a private 
static class. 



Hiding Named Helper Visitor inside of ToStringl 



Comments 



Singleton Pattern 



package listFW. visitor ; 
import listFW.*; 



public class ToStringlWithHiddenHelper implements IListAlgo { 



public static final 
ToStringlWithHiddenHelper Singleton = new 

private ToStringlWithHiddenHelper () { 
} 



ToStringlWithHiddenHelper () ; 



private static class HiddenHelper implement; 
public static final HiddenHelper Singleton : 

private HiddenHelper () { 
} 



The helper visitor has a name, HiddenHelper, and 

is defined privately and globally (static) inside of 

^y-SfeM^isibor ToStringlWithHiddenHelper. 
new HiddenHelper () ; 



public Object emptyCase(IMTList host, Objectl... ace) { 

return acc[0] + ")"; 

} 



public Object nonEmptyCase(INEList host, Ob; 
return host .getRestO .execute (this, acc[0] 
> 
> 



ect . . . ace) { 
", " + host.getFirstQ) ; 



continued on next page 
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public Object emptyCase(IMTList host, Object 

return "()"; 

} 

public Object nonEmptyCase(INEList host, Ob; 

return host . getRest () . execute (HiddenHelper . ^ 

} 

} 


The main visitor calls on its hidden helper singleton 

to help complete the job. 
. . . nu) { 

ect . . . nu) { 

>ingleton, "(" + host .getFirst ()) ; 





Table 3.20 



Hiding Named Helper Visitor inside of ToString2 



Comments 



package listFW. visitor ; 
import listFW.*; 

public class ToString2WithHiddenHelper 
public static final 
ToString2WithHiddenHelper Singleton = new 

private ToString2WithHiddenHelper() { 

> 



implements IListAlgo { 

T4String2WithHiddenHelper() ; 



IListAlgo { 

new HiddenHelper () ; 



private static class HiddenHelper implement; 
public static final HiddenHelper Singleton : 

private HiddenHelper () { 
} 



public Object emptyCase(IMTList host, Objectl... ace) { 

return "(" + acc[0] + ")"; 

} 



public Object nonEmptyCase(INEList host, Ob; 
return host .getRest () .execute (this, acc[0] 
} 
} 



ect. . . ace) { 
", " + host. getFirst () ) ; 



continued on next page 
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public Object emptyCase(IMTList host, Object 

return "()"; 

} 



public Object nonEmptyCase(INEList host, 
return host .getRest () . execute (HiddenHelper. 
} 
} 



nu) { 



Object. . . nu) { 
Singleton, host .getFirst () .toStringQ) ; 



Table 3.21 



Hiding Named Helper Visitor inside of ToString3 



Comments 



package listFW. visitor ; 
import listFW.*; 

public class ToString3WithHiddenHelper 
public static final 
ToString3WithHiddenHelper Singleton = new 

private ToString3WithHiddenHelper() { 
} 



implements IListAlgo { 

ToString3WithHiddenHelper() ; 



private static class HiddenHelper implement; 
public static final HiddenHelper Singleton : 

private HiddenHelper () { 

> 



public Object emptyCase(IMTList host, Object... nu) { 

return ")"; 

} 



IListAlgo { 

new HiddenHelper () ; 



public Object nonEmptyCase(INEList host, Ob" 
return ", " + host .getFirst () + host .getRest; 
} 
} 



ect . . . nu) { 

() .execute (this) ; 



continued on next page 
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public Object emptyCase(IMTList host, Object; 

return "()"; 

} 



public Object nonEmptyCase(INEList host, Ob" 
return "(" + host .getFirst () + host.getRest 
} 
} 



nu) { 



ect . . .bu) { 
{) . execute (HiddenHelper .Singleton) ; 



Table 3.22 



3.5.3 3. Anonymous Helpers 



Anonymous Helper Visitor inside of ToStringl Comments 



package listFW. visitor ; 
import listFW.*; 

public class ToStringlWithAnonymousHelper i 
public static final 
ToStringlWithAnonymousHelper Singleton = new 

private ToStringlWithAnonymousHelper () { 
} 



implements IListAlgo { 

ToStringlWithAnonymousHelper () ; 



private static final IListAlgo AnonymousHelper 
public Object emptyCase(IMTList host, Object; 
return acc[0] + ")"; 
} 



new IListAlgo () { 
. . . ace) { 



public Object nonEmptyCase(INEList host, Ob; 

return host .getRest() .execute (this, acc[0] 

} 

}; // PAY ATTENTION TO THE SEMI-COLON HERE! 



ect . . . ace) { 
", " + host. getFirst () ) ; 



continued on next page 
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public Object emptyCase(IMTList host, Object 

return "()"; 

} 


. . . nu) { 


public Object nonEmptyCase(INEList host, Object... nu) { 

return host .getRestO .execute (AnonymousHelper, "(" + host .getFirst ()) ; 

} 

} 







Table 3.23 



Anonymous Helper Visitor inside of ToString2 



Comments 



package listFW. visitor ; 
import listFW.*; 

public class ToString2WithAnonymousHelper i 
public static final 

ToString2WithAnonymousHelper Singleton = new 
private ToString2WithAnonymousHelper() { 
} 



implements IListAlgo { 

ToString2WithAnonymousHelper() ; 



private static final IListAlgo AnonymousHelper 
public Object emptyCase(IMTList host, Object; 
return "(" + acc[0] + ")"; 
} 



= new IListAlgo () { 
ace) { 



public Object nonEmptyCase(INEList host, Ob; 

return host .getRest() .execute (this, acc[0] 

} 

}; // PAY ATTENTION TO THE SEMI-COLON HERE! 



ect . . . ace) { 
", " + host. getFirst () ) ; 



continued on next page 
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public Object emptyCase(IMTList host, Object;... nu) { 

return "()"; 

} 

public Object nonEmptyCase(INEList host, Object... nu) { 

return host .getRest () . execute (AnonymousHelper, host .getFirst () .toStringO) ; 

} 

} 





Table 3.24 



Anonymous Helper Visitor inside of ToString3 



Comments 



package listFW. visitor ; 
import listFW.*; 

public class ToString3WithAnonymousHelper i 
public static final 
ToString3WithAnonymousHelper Singleton = new 

private ToString3WithAnonymousHelper() { 
} 



implements IListAlgo { 

ToString3WithAnonymousHelper() ; 



private static final IListAlgo AnonymousHelper 
public Object emptyCase(IMTList host, Object; 
return ")"; 
} 



= new IListAlgo () { 
nu) { 



public Object nonEmptyCase(INEList host, Ob" 

return ", " + host .getFirst () + host .getRest; 

} 

}; // PAY ATTENTION TO THE SEMI-COLON HERE! 



ect . . . nu) { 

() .execute (this) ; 



continued on next page 
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public Object emptyCase(IMTList host, Object; 

return "()"; 

} 



public Object nonEmptyCase(INEList host, Ob" 
return "(" + host .getFirst () + host.getRest 
} 
} 



nu) { 



ect . . . nu) { 
{) . execute (AnonymousHelper) ; 



Table 3.25 



3.5.4 4. Factory with Anonymous Inner Classes 



Comments 



package listFW. factory; 
import listFW.*; 

public class InnerCompListFact implements 
public static final InnerCompListFact Sing 

private InnerCompListFact () { 
} 



IListFactory { 

l4ton = new InnerCompListFact () ; 



private final static IListAlgo ToStrHelp 
public Object emptyCase(IMTList host, Object 
return acc[0] + ")"; 
} 

public Object nonEmptyCase(INEList host, 0b~ 

return host .getRest() .execute (this, acc[0] 

} 

}; // PAY ATTENTION TO THE SEMI-COLON HERE! 



IListAlgo () { 
. ace) { 



ect . . . ace) { 
11 , " + host. getFirst () ) ; 



continued on next page 
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private final static IMTList MTSingleton = i 


Lew IMTList (){ 


public Object execute (IListAlgo algo, Object 


. . . inp) { 


return algo. emptyCase (this, inp) ; 
} 




public String toStringO { 




return "()"; 

} 

}; // PAY ATTENTION TO THE SEMI-COLON HERE! 






public IMTList makeEmptyList () { 




return MTSingleton; 
} 






Note how the code inside the anonymous inner class 




references first and rest of the parameter list, first 


public INEList makeNEList (final Object firs! 


'aifd^kt^i^fedfl^^e in the closure of the anony- 


return new INEList () { 


mous inner class. Here is an important Java 


public Object getFirstO { 


syntax rule: For an local inner class defined in- 


return first; 


side of a method to access a local variable of the 


} 


method, this local variable must be declared as 




final. 


public IList getRestO { 




return rest; 
} 




public Object execute (IListAlgo algo, Object 


. . . inp) { 


return algo. nonEmptyCase (this, inp); 
} 




public String toStringO { 




return (String) rest .execute (ToStrHelp, "(" -\ 

y 

>; 

> 
> 


■ first) ; 


continued on next page 
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Table 3.26 

Click here to download the code of all of the above 13 . 

3.5.5 5. Classes defined inside of another Class 

Besides fields and methods, a Java class can also contain other classes. And just like a field or method 
defined inside of a class, a class defined inside of another class can be static or non-static. Here is the syntax. 

class X { 

// fields of X ... 

// methods of X ... 

/** 

* named class Y defined inside of class X: 

*/ 

[public | protected I private] [static] [final] [abstract] class Y [ extends A] [implements B] { 
// fields of Y ... 
// methods of Y ... 
// classes of Y ... 
} 
} 

3.5.5.1 Scope Specifier 

When an embedded class is defined as static, it is called a nested class. The members (i.e. fields, 
methods, classes) of a (static) nested class can access only static members of the enclosing 
class. 

When an embedded class is non- static, it is called an inner class. The members of an inner class can 
access ALL members of the enclosing class. The enclosing class (and its enclosing class, if any, and so on) 
contains the environment that completely defines the inner class and constitutes what is called the closure 
of the inner class. As all functional programmers should know, closure is a powerful concept. One of the 
greatest strength in the Java programming language is the capability to express closures via classes with 
inner classes. We shall see many examples that will illustrate this powerful concept in other modules. 

Inner classes do not have to be anonymous as shown in the above examples. They can be named as well. 

3.5.5.2 Access Specifier 

Just like any other class, a class defined inside of another class can be public, protected, package private, 
or private. 

3.5.5.3 Extensibility Specifier 

Just like a regular class, a final nested/inner class cannot extended. 

3.5.5.4 Abstract Specifier 

Just like a regular class, an abstract nested/inner class cannot be instantiated. 



3 http://cnx.org/content/ml7220/latest/listFW.zip 
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3.5.5.5 Inheritance Specifier 

Just like a regular class, an nested/inner can extend any non-final class and implement any number of 
interfaces that are within its scope. 

3.5.5.6 Usage 

Nested classes are used mostly to avoid name clash and to promote and enforce information hiding. Exam- 
ples? 

Inner classes are used to create (at run-time) objects that have direct access to the internals of the 
outer object and perform complex tasks that simple methods cannot do. Most of the time, they are defined 
anonymously. For examples, "event listeners" for Java GUI components are implemented as inner classes. 
The dynamic behavior and versatility of these "listeners" cannot be achieved by the addition of a set of fixed 
methods to a GUI component. We shall study Java event handling soon! 

An inner object can be thought as an extension of the outer object. 

3.5.6 6. Closure 

In functional programming, the closure of a function (lamdba) consists of the function itself and an environ- 
ment in which the function is well-defined. In Java, a function is replaced by a class. An inner class is only 
defined in the context of its outer object (and the outer object of the outer object, etc.). An inner class 
together with its nested sequence of outer objects in which the inner class is well-defined is the equivalent 
of the notion of closure in functional programming. Such a notion is extremely powerful. Just like knowing 
how to effectively use lambda expressions and higher order functions is key to writing powerful functional 
programs in Scheme, effective usage of anonymous inner classes is key to writing powerful 00 programs in 
Java. 

Some important points to remember about closures and inner classes: 

• An object's closure is defined at the time of its creation. 

• An object "remembers" its closure for its entire lifetime. 

• An inner object's closure includes any local variables that are declared as final, plus all fields of the 
enclosing object, including private ones. 

• Every time a factory method is run, where a new anonymous object is created, a new closure for that 
object is created. This is because the local variables could change between calls. 

• Closures enable decoupled communication because an inner class can communicate with its outer class 
through its closure. 

One of the most important ways in which we will use anonymous inner classes it to take advantage of their 
closure properties. Anonymous inner classes are the only objects in Java that can be instantiated in such 
a manner that the variables in their environments (closures) can be dynamically defined. That is, since an 
anonymous inner class can reference a local variable (that is declared final) and since local variables are 
created every time a method is called, then every the anonymous inner class object created has a different 
set of dynamically created variables that it is referencing. This means that we can make unique objects with 
unique behaviors at run time. 

Factories are a natural partner with anonymous inner classes. With a factory that returns anonymous 
inner classes, we can instantiate unique objects with unique behaviors. If the factory method takes in param- 
eters, there local variables can be used to alter the resultant object's behavior, a process called "currying 14 
" (named after the famous mathematician/computer scientist Haskell Curry 15 ). The objects made by the 
factory are then sent off to various odd and sundry different parts of our 00 system but all the while re- 
taining their closures, which were determined at the time of their instantiation. Thus they retain the ability 
to communicate back to the factory that made them even though they are being used in another part of the 

14 http://en. wikipedia.org/wiki/Currying 
15 http://www. haskell.org/bio. html 
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system that knows nothing about the factory. We like to call these "spy objects" because they act like 
spies from the factory. This gives us powerful communications even though the system is decoupled. 
This is the last piece of our abstraction puzzle! We have 

1. Abstract Structure - abstract classes, interfaces 

2. Abstract Behavior - abstract methods, strategies, visitors. 

3. Abstract Construction - factories 

4. Abstract Environments - anonymous inner classes, closures. 

3.5.6.1 Examples 

Example 1: Reversing a list using factory and anonymous inner class helper 

Write Reverse such that it takes one parameter, the IListFactory, but such that its helper only takes one 
parameter (other than the host list) which is the accumulated list. 

public class Reverse implements IListAlgo { 

public static final Reverse Singleton = new ReverseO; 

private ReverseO O 

public Object emptyCase(IMTList hostO, Object... fac) { 

return (( IListFactory) f ac [0] ) .makeEmptyList () ; 
} 

public Object nonEmptyCase(INEList hostO, Object... fac) { 

final IListFactory f = (IListFactory) fac[0]; // final so that the anon, inner class can access it. 
return hostO.getRest () .execute (new IListAlgo () { 

public Object emptyCase(IMTList hostl, Object... ace) { 

return ace [0] ; 
} 

public Object nonEmptyCase(INEList hostl, Object... ace) { 
return hostl .getRest() .execute (this, 

f.makeNEList (hostl. getFir st () , (IList) acc[0])); 
} 
},f .makeNEList (hostO.getFirst () , f .makeEmptyList ()) ) ; 
} 
} 

Example 2: Ant World 

Imagine a world of ants that live in a one-dimensional space. A queen ant can make a bunch of worker ants. 
Each time she gives birth to a worker ant, she gives it a name. A worker ant can always tell what its name 
is. A worker ant from a particular colony can always calculate its distance from its queen. A worker ant can 
also move its queen to a different location. Wherever the queen moves to, ALL of her workers always know 
their relative distance from her. We want to keep track of all the ants in our ant world and all the ants in 
each of the existing colonies. We want to model the fact that each queen produces its own worker ants, each 
one which can move its queen around without telling the other ants in the same colony, yet ALL of the ants 
in the same colony would know where their queen is. 

The above can be modeled by a Queen class with an abstract Worker inner class as shown below. This 
example illustrates the differences between static and non-static fields, methods and embedded classes. 
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/** 

* Models ants living in a 1 -dimensional world 
* 

* 

* The Worker inner objects have direct access to the location of its outer 

* Queen object. 
* 

* ©author A.L. Cox 

* ©author D.X. Nguyen 

* ©author S.B. Wong 

* ©since 02/07/2003 
*/ 

public class Queen { 
/** 

* The total number of ants (queens and workers for all the queens) that 

* currently exist in our ant world. 
* 

* Why is this field static? 
*/ 

private static int _ants; 

/** 

* The location of this Queen object with respect to 0. 
* 

* Why is this field non-static? 

*/ 

private int _origin; 

/** 

* The total numbers of living worker ants produced by this Queen object. 
* 

* Why is this field non-static? 
*/ 

private int .workers; 

/** 

* Is part of a Queen instance, just like the origin field and the 

* makeWorkerO method are parts of a Queen instance. 

* Any concrete implementation of Worker must implement the getNameO 

* method to return the name given by its Queen at birth time. 
* 

* Why can't this class be static? 
*/ 

public abstract class Worker { 

/** 

* The location of this Worker object. 

*/ 

private int .location; 

/** 

* Increments _ants and .workers because every time a Worker is 

* instantiated, a new ant is added to our ant world, a new worker ant 
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3.5.6.1.1 Exercise: 

Write a JUnit test program for the Queen and Worker classes. 



3.5 



.7 7. Changing "states" - progressing to non-functional programming 



In the above Queen example, the locations of a Queen object and its Worker objects are subject to change. 
Every time a Worker ant moves its Queen, it has the side effect of changing the Queen's origin. The Queen 
object remains the "same". This seems like a reasonable thing to have. In the functional programming 
paradigm, to move the Queen, the Worker ant would have to instantiate a new Queen object with a new 
location and find a way to associate itself to this new Queen, which does not seem to model the "real" 
ant world very well. By allowing our objects to change their internal states in appropriate situations, our 
programming model becomes more "realistic", more efficient, and in many cases "simpler". 

To further illustrate the relevance of state changes, consider the problem of moving the minimum element 
of a list of integers to the front of the list. Since the current IList model is immutable, we can only solve 
the problem by returning a copy of the original list with its minimum at the front. Below is an algorithm 
to solve the problem that makes use of an accumulator to accumulate the current minimum and internally 
updates it as the list is being traversed. (Note: the list is assumed to hold no duplicate values). 
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Min2Front .Java 



public class Min2Front implements IListAlgo { 

private Integer _accMin; // accumulated min. 
private IListFactory _fact; 

public Min2Front (IListFactory f) { 

_fact = f ; 
} 

public Object emptyCase(IMTList mtHost, Object... nu) { 

return mtHost ; 
} 

public Object nonEmptyCase(INEList neHost, Object... nu) { 

// We assign _accMin the first of L as a candidate for minimum: 

_accMin = (Integer) neHost .getFirst () ; 

/** 

* Let us consider the set S of all elements in L that precede L. 

* S is clearly empty. At this point we have established the following: 

* _accMin is an element of L and is smaller than all elements of S. 

* We now call on an anonymous helper to operate on L in order to find 

* the minimum and remove it from L. This helper will recursively 

* travese L to the end in order to obtain the minimum, save it in 

* _accMin and reconstruct the host list L without the minimum on its way 

* back from the recursive list traversal. 
*/ 

IList withoutMin = (IList)neHost .execute (new IListAlgo () { 
/** 

* Note: when L executes this helper, this case is called since L is 

* not empty. Thus for the first call to this method, h is L. 

* We update _accMin to ensure that it is an element of L and is the 

* minimum of all elements in L that precedes the rest of the host 

* parameter h. Then we recursively call this helper on h.getRestO 

* to save the minimum in _accMin and create a copy of h.getRestO 

* that does not contain _accMin. 
*/ 

public Object nonEmptyCase(INEList h, Object... nu) { 
if ( (Integer)h. getFirst () < accMin) { 
_accMin = first; 

} 
/** 

* At this point, we have established the following invariant: 

* _accMin is an element of L and is the minimum of all elements 

* in L that precedes h.getRestO. 
*/ 

IList accList = (IList)h.getRest () .execute (this, null); 
/** 

* By induction, _accMin is now the minimum of the whole outer 

* host list L, and accList is a copy of h.getRestO that does 

* not contain _accMin. 
*/ 

if ( !f irst . equals (_accMin)) { 

accList = _f act .makeNEList (first , accList); 
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In the above, the comments are longer than the code. The above code and comments can be greatly 
simplified if the list is mutable. What does it mean for a list to be mutable? 



Chapter 4 

Mutable Data Structures 

4.1 State Design Pattern 1 

When modeling real-life systems, we often find that certain objects in our system seem to change "state" 
during the course of a computation. 
Examples of changing state: 

1. A kitten grows up into a cat 

2. A car runs into a telephone pole and becomes a wreck. 

3. A friend is sad one day, happy another, and grumpy on yet another day. 

4. A list changes from empty to non-empty when an element is added. 

5. A fractal becomes more complex when it grows 

6. etc. etc. 

The cat and the kitten are the same animal, but they don't act identically. A car can be driven but a wreck 
cannot-yet they are the same entity fundamentally. Your friend is the same human being, no matter what 
their mood. Why shouldn't a list be the same list and a fractal be the same fractal? 

When something changes state, it is the same object, but yet it behaves differently. This 
phenomenon of having an objects change its behavior as if it were suddenly belonging to a whole different 
class of objects is called "dynamic reclassification". 

So far we've been using immutable data, and to create a non-empty list from an empty one, required that 
we make a whole brand-new list. With our use assignment (" = ") previously, we've changed the value of 
a variable, but never the behavior the object it references. 

Consider this notion: We want to change the type of the object but we want to encapsulate that 
change so that the outside world does not see the type change, only the behavior change. 

Let's work with an example: 

Remember the old arcade game, "Frogger"? That's the one where a traffic-challenged amphibian attempts 
to hop across multiple lanes of speeding cars and trucks, hopefully without being converted into the road- 
kill- du-j our. 

(Here's an on-line version: http://www.gamesgnome.com/arcade/frogger/ 2 ) 

Well, let's look at what a frog is here: 

A live frog 

• Has a well-defined position 

• Has a green color 

• Can move from place to place 

lr rhis content is available online at <http://cnx.Org/content/ml7225/l. 3/>. 
2 http://www. gamesgnome.com/arcade/frogger/ 
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• Dies when hit by a vehicle. 
On the other hand, a dead frog 

• Has a well-defined position 

• Has a decided red color. 

• Cannot move from place to place 

• Doesn't die when hit by a vehicle because it is already dead. 

Using our trusty separation of variant and invariant, we can see that the position of a frog is an invariant but 
all the other behaviors are variants. Thus we want to separate out these variants into their own subclasses 
of an invariant abstract class. We then use composition to model the frog having an abstract state, which 
could be either alive or dead: 
Download the code here. 3 



«IFrog» 


+ Point : getPosQ 
+ Color : getColorfj 
+ Point : moveBytPoint 
+ IFrog : getHitQ 


delta) 



1 



~ Point : _poa 

~ AFroptate : _?tate 



< ,- -"contest» 
Fro* 



+ Point : getPosQ 

+ Color :getColorQ 

+ Point : moveBy(Point delta) 

+ IFrog : getHitQ 

void : setState(AFrogState s) 



delegates to 



-± 



■■' -abstract state» 
AFrogStaie 



Color : getColor(Frog context) 

Point : moveBy(Frog context, Point delta) 

JFwE -' g&tHft(Frog context) 



J. 



«concrete state» 
Live State 



Lave State 'ij: 1 ^'.?:?:. 



' LiveStateQ 
Color : getColor(Frog content) 
Point : moveBy(Frog content, Point delta) 
EFrog : getHIt(Frog content) 



«concrete state» 
DeadState 



Dead State : 5i:]g1eto:] 



' DeadStateO 
Color : getColor(Frog host) 
Point : moveBy(Frog host, Point delta) 
EFrog : getHit(Frog host) 



Figure 4.1 



Click here to download the full javadoc documentation of the above code. 4 

The variant behaviors are represented by the abstract AFrogState, with the DeadState and LiveState 
implementing its abstract behaviors. 

(Note: The IFrog interface is there simply to allow different formulations of the frog to exist. See the 
Question (Section 4.1.3: Question:) below.) 



3 http://cnx.org/content/ml7225/latest/frog.zip 
4 http://cnx.org/content/ml7225/latest/frogDocs.zip 



87 

For those variant behaviors, all the main Frog does is to delegate (pass the call on to and return the 
result of) to the _state that it has. If the _state is a LiveState, then the Frog will act as if were alive 
because the LiveState only contains live-like behaviors. On the other hand, if the state is a DeadState, then 
the delegation to the _state will produce dead-like behavior. The LiveState's getHit behavior will cause 
the Frog's _state to change from referencing a LiveState instance to referencing a DeadState instance. 

4.1.1 No conditionals are needed!! 

4.1.2 The Frog behaves the way it does because of what it is at that moment, 
not because of what it can figure out about itself then. 

This is an example of the State Design Pattern. Click here for more information on the State design pattern. 5 
From the outside, nothing about the internal implementation of Frog can be seen. All one can see is 
its public behavior. The implementations of the state design pattern are completely encapsulated (within 
the frog package, in this formulation).. For instance, if one is moving a live Frog, it will dutifully move as 
directed, but if in the middle somewhere, the Frog is hit, then it will immediately stop moving, no matter 
how much it is asked to do so. If one is checking its color, the live Frog is a healthy green but right after its 
accident, it will report that it is deathly red. 

Notice how the Frog changes its behavior and always behaves correctly for its situation, with no con- 
ditional statements whatsoever. 

4.1.3 Question: 

A very nice technique, when it is possible, is to implement the State pattern using anonymous inner classes. 
Can you write an IFrog implementation that encapsulates the states using nested class (es) and anonymous 
inner class (es)? 

• It can be done using only one publicly visible class and no package visible classes at all. 

• The only methods needed are those specified by IFrog. 

• How does using anonymous inner class (es) reduce the number of parameters passed to the state? 

• How does using the anonymous inner class (es) reduce the number of non-public methods? 



4.1.4 Onward! 

Looking way back to the beginning of the semester, we now have to ask, "Can we use this technology to 
create a mutable list? How will this affect the visitors and their execute function?" Hmmmm 

4.2 Mutable Linear Recursive Structure 6 

4.2.1 1. State Pattern and Dynamic Reclassification 

In programming, it is often necessary to have objects with which one can store data, retrieve data when 
needed, and remove data when no longer needed. Such objects are instances of what we call container 
structures. 

A mutable container structure is a system that may change its state from empty to non-empty, and 
vice- versa. For example, an empty container changes its state to non-empty after insertion of an object; and 
when the last element of a container is removed, its changes its state to empty. Figure 1 below diagrams the 
state transition of a container structure. 



5 "State Design Pattern" <http://cnx.org/content/ml7047/latest/> 

6 This content is available online at <http://cnx.org/content/ml7265/!. l/>. 
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Container Structure State 



remove(k) 

insert (k, v) 
Empty | ft* 



remove(k) [not last element] 




Non-empty 1 jnsert(k, v) 



remove(k) [last element] 



Figure 1: State diagram for a container structure. 



Figure 4.2: State transition diagram for container structures 



For each distinct state, the algorithms to implement the methods differ. For example, the algorithm for 
the retrieve method is trivial in the empty state -it simply returns null- while it is more complicated in the 
non-empty state. The system thus behaves as if it changes classes dynamically. This phenomenon is called 
"dynamic reclassification." The state pattern is a design solution for languages that do not directly support 
dynamic reclassification. This pattern can be summarized as follow. 

• Define an abstract class for the states of the system. This abstract state class should provide all the 
abstract methods for all the concrete subclasses. 

• Define a concrete subclass of the above abstract class for each state of the system. Each concrete state 
must implement its own concrete methods. 

• Represent the system by a class, called the context, containing an instance of a concrete state. This 
instance represents the current state of the system. 

• Define methods for the system to return the current state and to change state. 

• Delegate all requests made to the system to the current state instance. Since this instance can change 
dynamically, the system will behave as if it can change its class dynamically. 

Below is the UML class diagram for the state design pattern 7 . 

7 "State Design Pattern" <http://cnx.org/content/ml7047/latest/> 
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Forwards all public method calls to the state: 
_state.aBeriavior(inp ; this); 



Context 



■ AState : state 



+ Object : aBehavior(Obiect mp) 
AState : getStateQ 
void : setState(A3tate state) 



-M 



Object : aBehavior (Objecting, Context owner) 



State 1 



Object : aBehavior(Ubiect mp, Context owner) 



State2 



Object : aBehavion'Object mp, Context owner) 



StateN 



Object : aBehavioit'Object itip. Context owner) 



Have disctinct concrete behaviors and may L_^, 
cause the context to change its state. 



Figure 4.3: UML class diagram for the state design pattern 



4.2.2 2. Mutable Linear Recursive Structure Framework 

A mutable linear recursive structure (LRStruct) can be in the empty state or in a non-empty state. If it 
is empty, it contains no object. Otherwise, it contains an object called first, and a LRStruct object called 
rest. When we insert a data object into an empty LRStruct, it changes it state to non-empty. When we 
remove the last element from an non-empty LRStruct, it changes its state to empty. We model a LRStruct 
using the state pattern, and as in the case of the immutable list, (Section 3.3) we also apply the visitor 
pattern to obtain a framework. Below is the UML class diagram of the LRStruct framework. Because of 
the current limitation of our diagramming tool, we are using the Object [] input notation to represent the 
variable argument list Object. . . input. Click here to download the code 8 . Click here to download the 
javadoc documentation. 9 . We will study the implementation code in the next lecture. 



8 http://cnx.org/content/ml7265/latest/lrs.zip 
9 http://cnx.org/content/ml7265/latest/lrsdocs.zip 
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<IAlgO>: 



+ Object : enipftGxsefLPJltruct host, Objectilinp) 

+ Object : nonE7nptpCase(LSStnci host, Object[] inp) 



I 
I 
I ' 



operates on 



LRStruct 



■ ANode : 



+ LRStructQ 

+ String : toStringQ 

+ LRStruct : insertFront(Object dat) 

+ Object : removeFiiont() 

+ Object : getFirstQ 

+ LRStruct : setFirst(Object dat) 

+ LRStruct : getRestQ 

+ LRStruct : setRest(LRStruct tail) 

+ Object : execute(IAlgo algo, Object Q inp) 
LRStruct(ANode node) 
LRStruct : setHead(ANode head) 
ANode : getHeadQ 



v\ 



" Object : _dat 
■ LRStruct : tail 



-4- 



State Design Pattern. LA, 

LRStruct delegates all public method calls to its state, _head, 

passing itself and all required parameters. 

ANode is the state and has package-private methods to 

"abstractly" do the job. EmptyNode and NENode are 

concrete states and can call LRStruct to change its state 

dynamically. 



^abstract state» 
ANode 



String : toString(LRStruct owner) 

LRStruct : getRest(LRStruct owner) 

Object : getFirst(LPUfiruct owner) 

LRStruct : $etRe$t{LRStruct owner, LRStruct tail) 

LRStruct : setFirst(LRStruct owner, Object dat) 

LRStruct : insertFronifZRSb'iict owner, Object dat) 

Object : removeFrontfLRStruct owner) 

Object : executet'LFLStruct owner, lAlgo algo, Objectfjinp) 



+ NENode(Object dat, LRStruct tail) 
LRStruct : getRest(LRStruct owner) 
Object : getFirst(LRStruct owner) 
LRStruct : setRest(LRStruct tail, LRStruct owner) 
LRStruct : setFirst(LRStruct owner, Object first) 
LRStruct : insertFront(LRStruct owner, Object dat) 
Object : removeFront(LKStruct owner) 
Object : execute(LRStruct owner, I Algo algo, Object Q input) 



EmptyNode 



EmptyNode : Singleton 



" EmptyNodeQ 
LRStruct : getRest(LRStruct owner) 
Object : getFirst(LRStruct owner) 
LRStruct : setRest(LRStruct owner, LRStruct tail) 
LRStruct : setFirst(LRStruct owner, Object dat) 
LRStruct : insertFront(LRStruct owner, Object dat) 
Object : removeFront(LRStruct owner) 
Object : exficute(LRStruct owner, I Algo algo, Object □ inp) 



Figure 4.4: State and Visitor Patterns for Mutable Linear Recursive Structure 

The public constructor: 

• LRStruct () 
and the methods: 

• insertFront (...) 

• removeFront (...) 

• getFirstO 

• setFirst ( . . . ) 

• getRestO 

• setRest( . . . ) 

of LRStruct expose the structure of an LRStruct to the client and constitute the intrinsic structural 
behavior of an LRStruct. They form a minimal and complete set of methods for manipulating an 
LRStruct. Using them, a client can create an empty LRStruct, store data in it, and remove/retrieve data 
from it at will. 
The method, 
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• Object execute (IAlgo algo, Object inp) 

is called the extensibility "hook". It allows the client to add an open-ended number of new application- 
dependent behaviors to the data structure LRStruct, such as computing its length or merging one LRStruct 
with another, without modifying any of the existing code. The application-dependent behaviors of LRStruct 
are extrinsic behaviors and are encapsulated in a union represented by a visitor interface called IAlgo. 

When a client programs with LRStruct, he/she only sees the public methods of LRStruct and IAlgo . To 
add a new operation on an LRStruct, the client writes appropriate concrete classes that implements IAlgo. 
The framework dictates the overall design of an algorithm on LRStruct: since an algorithm on LRStruct 
must implement IAlgo , there must be some concrete code for emptyCase( . . . ) and some concrete code for 
nonEmptyCase (...). For example, 

public class DoSomethingWithLRS implements IAlgo { 
// fields and constructor code... 
public Object emptyCase (LRStruct host, Object... inp) { 

// some concrete code here... 

return some Object; // may be null. 
} 

public Object nonEmptyCase (LRStruct host, Object... inp) { 
// some concrete code here... 
return some Object; // may be null. 
} 
} 

As illustrated in the above, an algorithm on LRStruct is "declarative" in nature. It does not involve 
any conditional to find out what state the LRStruct is in in order to perform the appropriate task. It simply 
"declares" what needs to be done for each state of the host LRStruct, and leaves it to the polymorphism 
machinery to make the correct call. Polymorphism is exploited to minimize flow control and reduce code 
complexity. 

To perform an algorithm on an LRStruct, the client must "ask" the LRStruct to "execute" the algorithm 
and passes to it all the inputs required by the algorithm. 

LRStruct myList = new LRStruct (); // an empty list 

// code to call on the structural methods of myList, e.g. myList . insertFront (/*whatever*/) 

// Now call on myList to perform DoSomethingWithLRS: 

Object result = myList .execute (new DoSomethingWithLRS (/* constructor argument list */) , -2.75, "abc"); 

Without knowing how LRStruct is implemented, let us look an example of an algorithm on an LRStruct 

4.2.3 3. Example 

Consider the problem of inserting an Integer object in order into a sorted list of Integers. Let us contrast 
the insert in order algorithms between IList, the immutable list, and LRStruct, the mutable list. 
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Insert in order using factory 



import listFW.*; 

public class Insert InOrder implements IList/. lgu>bX 
private IListFactory _fact; 



public Insert InOrder (IListFactory If) { 

.fact = If; 
} 



/** 



* 
* 
* 
* 
* 
*/ 



Simply makes a new non-empty list with 
parameter n as first. 
Oparam host an empty IList. 
@param n n[0] is an Integer to be 
©return INEList. 



public Object emptyCase(IEmptyList host, 

return _f act .makeNEList (n[0] , host); 
} 



/** 



Based on the comparison between first 
creates a new list or recur! 
@param host a non-empty IList . 
@param n an Integer to be inserted in 
©return INEList 



* 
* 
* 
* 
* 

*/ 

public Object nonEmptyCase (INEList host, 
return ( Integer) n[0] < ( Integer) host .g< 
_f act .makeNEList (n[0] , host) : 
_f act . makeNEList (host . getFirst ( ) , 

(IList)host .getRest () 
} 



Insert in order using mutation 



import Irs . * ; 

ic class InsertlnOrderLRS implements IAlgo { 
public static final InsertlnOrderLRS Singleton 



= new InsertlnOrderLRS C 



private InsertlnOrderLRS () { 
} 

/** 
tthe gi&enply inserts the given parameter n at 

* @param host an empty LRStruct . 

* @param n n[0] isan Integer to be inserted 
inserted 4n@r>ffi1iern ibftSttost . 

*/ 

public Object emptyCase (LRStruct host, Object... n) { 
Ob j ectretun^ Host . insertFront (n [0] ) ; 
} 



/** 

* Based on the comparison between first ai^d n, 
aitd n>$ inserts at the front or recurs! 

* @param host a non-empty LRStruct . 

* @param n n[0] is an Integer to be inserted in order : 
oifder* i®±etihiDBtLRStruct 

*/ 

public Object nonEmptyCase (LRStruct host, 
Clbjectif . (ft!nt[eger)n[0] < (Integer) host .getFi(rst 
ejtFirst Orelturn host . insertFront (n [0] ) ; 
} 

else { 
executei(&tLUBn kcKttl )^§t Rest () .execute (this, n[0]); 

> 
> 



continued on next page 



the front . 
in order int 



Object ... n) ^ 

o) { 
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Note that the insert in order algorithm for LRStruct need not create any new list and thus needs no 
factory. Download the above code: Irs. zip 10 



Table 4.1 



4.3 Binary Tree Structure 11 

Up until now, we have been organizing data in a "linear" fashion: one item after another. The corresponding 
data structures are the immutable scheme list (iList) and the mutable linear recursive structure (LRStruct). 
Now, suppose we want to model something like the following organization chart. 



NornE Inc. 




■ 



CFO 



i 



CTO 



COO 



■ ■ 



Director A Director B Manager A ACOO 



Figure 4.5 



A structure of data such as the above is called a tree. We first design a special kind of mutable tree 
structure called binary trees. 



4.3.1 1. Binary Tree Object Model 

Definition 4.1: Binary Tree 

A (mutable) binary tree, BiTree, can be in an empty state or a non-empty state: 

• When it is empty, it contains no data. 

• When it is not empty, it contains a data object called the root element, and 2 distinct BiTree 
objects called the left subtree and the right subtree. 

10 http://cnx.org/content/ml7265/latest/lrs.zip 

n This content is available online at <http://cnx.org/content/ml7289/!. 2/>. 



94 



CHAPTER 4. MUTABLE DATA STRUCTURES 



We implement the above object structure with a combination of state/composite/ visitor patterns, in a 
manner analogous to LRStruct 12 . 

Below is the public interface of the binary tree framework. Click here for javadoc documentation. 13 



■=:■=: IVmtor=> 



+ Object : emptyCasefBiTres host, ObjectjJ inp) 
+ Object : nonEmpfyCasetBiTree host, Object[]mp) 



calls on | 

i 



Represents all binary 
trees algorithms. 



"K 



i 

I operates on 

i 
1 



Visitor Pattern 



BiTree 



+ BiTreeQ 

+ Object : getRootDatQ 

+ void : setRjootDat(Object dat) 

+ BiTree : getLeftSubTree() 

+ BiTree : getRightSubTree() 

+ void : setLeftSubTree(BiTree biTree) 

+ void : setRightSubTree(BiTree biTree) 

+ void : insertRjoot(Object dat) 

+ Object : remRjoot() 

+ Object : execute(I Visitor algp, Object Q inp) 

+ String : toStringQ 



insertRjoot(): only on an empty tree. 

remRDotQ: only on trees with at least one empty subtree 

toStringQ: prints this tree vertically. 



K 



NOTE: Due to the limitation of the current UML tool, 
we use the array notation Object Q inp to represent the 
varargs notation Object... inp. 



T\ 



Figure 4.6 



The implementation details are given in the following UML class diagram. Click here for javadoc docu- 
mentation. 14 



12 http://cnx.org/content/ml7289/latest/lrs-javadocs.zip 
13 http://cnx.org/content/ml7289/latest/brs-javadocs.zip 
14 http://cnx.org/content/ml7289/latest/brs-javadocs.zip 
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To String 



1 ToString : Singleton 



~ ToStringQ 

+ Object : emptyCase(BiTree host, Object Q mi) 

+ Object : nonEmptyCase(BiTree host, Object Q nu) 



T 



ToStiingHelp 



+ ToStiingHelp : Singleton 



~ ToStringHelpQ 

+ Object : emptyCase(BiTree host, Object Q nu) 

+ Object : nonEmptyCase(BiTree host, Object Q leftLead) 



I 



BiTree 



— ANode : rootNode 



- _ operate^ on^ 



+ BiTreeQ 

+ Object : getRjootDatQ 

+ void : setRjootDat(Object dat) 

+ BiTree : getLeftSubTreeQ 

+ BiTree : getRightSubTree() 

+ void : setLeftSubTree(BiTree biTree) 

+ void : setRightSubTree(BiTree biTree) 

+ void : insertRjoot(Object dat) 

+ Object : remRootQ 

+ Object : executed Visitor algo, Object Q inp) 

+ String : toStringQ 

void : setRjootNode(ANode node) 

ANode : getRootNodeQ 



l/^eft l/^ight 



J_ 



caUson 



> 



«IVmtoi» 



+ Object : emptyCasefBiTree host, Object[]inp) 
+ Object : nonEmptyCasefBiTree host, Object[]inp) 



-sl- 



i_ 



DatNode 



~~ BiTree : _leftTree 

— Object : _dat 

~ BiTree : _rightTree 



+ DatNode(Object dat) 

Object : getRjootDat(BiTree owner) 

void : setRjootDat(Object dat, BiTree owner) 

BiTree : getLeftSubTree(BiTree owner) 

BiTree : getRightSubTree(BiTree owner) 

void : setLeftSubTree(BiTree biTree, BiTree owner) 

void : setRightSubTree(BiTree biTree, BiTree owner) 

void : insertRjoot(Object dat, BiTree owner) 

Object : reinRjoot(final BiTree owner) 

Object : execute(BiTree owner, I Visitor algp, Object Q inp) 



ANode 



Object : getRootDat{BiTree owner) 

void : setRootDat(Object dat, BiTree owner) 

BiTree : getLeftSiibTree (BiTree owner) 

BiTree : getRightSubTree{BiTree owner) 

void : setLeftSubTreeiBiTree biTree, BiTree owner) 

void : setRightSubTreefBiTree biTree, BiTree owner) 

void : insertRoot(Object dat, BiTree owner) 

Object : remS&ot{BiTree owner) 

Object : execute(BiTree owner, Msitor algo, Object[]inp) 



EniptvNode 



EmptyNode : Singleton 



" EmptyNodeQ 
Object : getRjootDat(BiTree owner) 
void : setRnotDat(Object dat, BiTree owner) 
BiTree : getLeftSubTree(BiTree owner) 
BiTree : getRightSubTree(BiTree owner) 
void : setLeftSubTree(BiTree biTree, BiTree owner) 
void : setRightSubTree(BiTree biTree, BiTree owner) 
void : insertRjoot(Object dat, BiTree owner) 
Object : reinRjoot(BiTree owner) 
Object : eHecute(BiTree owner, IVisitor algo, Object □ inp) 



NOTE: Due to the limitation of the current UML tool, 
we use the array notation Object Q inp to represent the 
varargs notation Object... inp. 



"K 



Figure 4.7 
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4.3.2 2. Implementation Details 

NOTE: Click here for source code. 15 

The code for BiTree is trivial, as it simply delegates most calls to its state, the root node. The real work is 
done in the state. The code for EmptyNode and DatNode for the most part are equally trivial. The insertion 
and removal of the root data of a BiTree require some work and need some explanation. When does it make 
sense to remove the root node from a (binary) tree? That is, when can one unambiguously remove the root 
node from a binary tree? 

Clearly, when both subtrees of a root node are non-empty, then removing the root node is problematic. 
However, it makes sense to allow root removal when at least one of the subtrees is empty. Suppose one of 
the subtrees is empty, then BiTree. remRoot () will change the state of this BiTree to the state of the other 
subtree. For example, when the left subtree is empty, root removal of the parent tree will set the parent tree 
to its right subtree. 



(a) (b) 
EmpatN- 
tyNede 
ode 

Figure 4.8: (a) EmptyNode (b) DatNode 



4.3.3 3. The Best Tree Printing Algorithm in Texas 

Consider the binary tree displayed in the following "horizontal" manner: 



62 



I I 
20 7 
I I 

I III 
[ ] 18 [ ] [ ] 
I 

I I 

39 [ ] 

I 

I I 

[ ] [ ] 

Such horizontal display of a tree is not very convenient when the tree is wide. It is more convenient to 
display the tree in a "vertical" manner. 

The following visitor and its helper print the above tree "vertically" as shown below: 

62 



3 http://cnx.org/content/ml7289/latest/brs. zip 
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Let's study the algorithm. 



(a) (b) 
Figure 4.9 



4.4 Arrays and Array Processing 16 

There are many ways to store data. So far, we have covered linear recursive structures, lists, and binary 
recursive structures, trees. Let's consider another way of storing data, as a contiguous, numbered (indexed) 
set of data storage elements: 
anArray = 



itemA 


itemB 


itemC 


itemD 


itemE 


itemF 


itemG 


itemH 


iteml 


itemJ 





1 


2 


3 


4 


5 


6 


7 


8 


9 



Table 4.2 

This "array" of elements allows us to access any individual element using a numbered index value. 

Definition 4.2: array 

At its most basic form, a random access data structure where any element can be accessed by 
specifying a single index value corresponding to that element. 
Example 

anArray [4] gives us itemE. Likewise, the statement anArray [7] = 42 should replace itemH with 
42. 



NOTE: Notice however, that the above definition is not a recursive definition. This will cause 
problems. 



16 This content is available online at <http://cnx.org/content/ml7258/!. 2/>. 
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4.4.1 Arrays in Java 

• Arrays... 

• are contiguous (in memory) sets of object references (or values, for primitives), 

• are objects, 

• are dynamically created (via new), and 

• may be assigned to variables of type Object or primitives 

• An array object contains zero or more unnamed variables of the same type. These variables are 
commonly called the elements of the array. 

• A non-negative integer is used to name each element. For example, arrayOf Ints[i] refers to the 
i+lst element in the array Of Ints array. In computer-ese, an array is said to be a "random access" 
container, because you can directly (and I suppose, randomly) access any element in the array. 

• An array has a limited amount of intelligence, for instance, it does know its maximum length at all 
times, e.g. arrayOf Ints. length. 

• Arrays have the advantage that they 

• provide random access to any element 

• are fast. 

• require minimum amounts of memory 

More information on arrays can be found in the Java Resources web site page on arrays 17 
NOTE: Arrays are size and speed at a price. 

4.4.1.1 Array Types 

• An array type is written as the name of an element type followed by one or more empty pairs of square 
brackets. 

• For example, int [] is the type corresponding to a one-dimensional array of integers. 

• An array's length is not part of its type. 

• The element type of an array may be any type, whether primitive or reference, including interface 
types and abstract class types. 



4.4.1.2 Array Variables 

• Array variables are declared like other variables: a declaration consists of the array's type followed by 
the array's name. For example, double [] [] matrixOf Doubles; declares a variable whose type is a 
two-dimensional array of double-precision floating-point numbers. 

• Declaring a variable of array type does not create an array object. It only creates the variable, which 
can contain a reference to an array. 

• Because an array's length is not part of its type, a single variable of array type may contain references 
to arrays of different lengths. 

• To complicate declarations, C/C++-like syntax is also supported, for example, 

double rowvector[] , colvector[] , matrix [] [] ; 
This declaration is equivalent to 

double [] rowvector, colvector, matrix [] ; 
or 



7 http://www.exciton.es. rice.edu/JavaResources/ Java/declarations. htm# Arrays 
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double [] rowvector, colvector; 
double [] [] matrix; 

Please use the latter! 



4.4.1.3 Array Creation 

• Array objects, like other objects, are created with new. For example, String [] arrayOf Strings = 
new String [10] ; declares a variable whose type is an array of strings, and initializes it to hold a 
reference to an array object with room for ten references to strings. 

• Another way to initialize array variables is 

int[] array0flTo5 = {1,2,3,4,5}; 
String [] arrayOf Strings = { "array", 

"of", 

"String" }; 
Widget [] arrayOf Widgets = { new Widget (), new Widget () }; 

• Once an array object is created, it never changes length! int [] [] arrayOf ArrayOf Int = {{ 1, 2 
}, { 3, 4 }}; 

• The array's length is available as a final instance variable length. For example, 

int[] array0flTo5 = { 1, 2, 3, 4, 5 }; 
System . out . print In (arrayOf 1To5 . length) ; 

would print "5". 



4.4.1.4 Array Accesses 

• Indices for arrays must be int values that are greater than or equal to and less than the length of 
the array. Remember that computer scientists always count starting at zero, not one! 

• All array accesses are checked at run time: An attempt to use an index that is less than zero or greater 
than or equal to the length of the array causes an IndexOutOf BoundsException to be thrown. 

• Array elements can be used on either side of an equals sign: 

• my Array [i] = aValue; 

• someValue = myArray[j] ; 

• Accessing elements of an array is fast and the time to access any element is independent of where it is 
in the array. 

• Inserting elements into an array is very slow because all the other elements following the insertion 
point have to be moved to make room, if that is even possible. 



4.4.2 Array Processing Using Loops 

More information on loops can be found at the Java Resources web site page on loops 18 . 

The main technique used to process arrays is the for loop. A for loop is a way of processing each 
element of the array in a sequential manner. 

Here is a typical for loop: 



3 http://www.exciton.es. rice.edu/JavaResources/ Java/loops. htm 
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II Sum the number of elements in an array of ints, myArray. 
int sum =0; // initialize the sum 

for(int idx=0; idx < myArray . length ; idx++) { //start idx @ 0; end idx at length- 1; 

//increment idx every time the loop is processed, 
sum += myArray [idx] ; // add the idx'th element of myArray to the sum 
} 

There are a number of things going on in the above for loop: 

• Before the loop starts, the index idx is being declared and initialized to zero, idx is visible only 
within the for loop body (between the curly braces). 

• At the begnning of each loop iteration, the index idx is being tested in a "termination condition", 
in this case, idx is compared to the length of the list. If the termination condition evaluates to false, 
the loop will immediately terminate. 

• During each loop iteration, the value of the idx's element in the array is being added to the running 
sum. 

• After each loop iteration, the index idx is being incremented. 

One can traverse an array in any direction one wishes: 

// Sum the number of elements in an array of ints, myArray. 
int sum = 0; // initialize the sum 

for (int idx=my Array. length- 1; 0<=idx; idx--) { //start idx @ length- 1; end idx at 0; 

//decrement idx every time the loop is processed, 
sum += myArray [idx] ; // add the idx'th element of myArray to the sum 
} 

The above loop sums the list just as well as the first example, but it does it from back to front. Note 
however, that we had to be a little careful on how we initialized the index and how we set up the termination 
condition. 

Here's a little more complicated loop: 

// Find the index of the smallest element in an array of ints, myArray. 
int minldx = 0; // initialize the index. Must be declared outside the loop. 

if (0==my Array. length) throw new NoSuchElementExcept ion ("Empty array!"); // no good if array is empty! 
else { 

for (minldx = 0, int j = 1; j <myArray . length ; j++) { //start minldx @ 0, start index @ 1 ; 

//end index at length- 1; increment index every 1 
if (myArray [minldx] > myArray [ j ] ) 

minldx = j ; // found new minimum 
} 
} 

Some important things to notice about this algorithm: 

• The empty case must be checked explicitly — no polymorphism to help you out here! 

• The desired result index cannot be declared inside the for loop because otherwise it won't be visible 
to the outside world. 
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• Be careful about using the minldx value if the array was indeed empty-it's an invalid value! It can't 
be set to a valid value because otherwise you can't tell the difference between a value that was never 
set and one that was. 

• The for loop has two initialization statements separated by a comma. 

• The loop does work correctly if the array only has one element, but only because the termination check 
is done before the loop body. 

• Notice that to prove that this algorithm works properly, one must make separate arguments about 
the empty case, the one element case and the n-element case. Contrast this to the much simpler list 
algorithm that only needs an empty and non-empty cases. 

For convenience, Java 5.0 now offers a compact syntax used for traversing all the elements of an array or of 
anything that subclasses type Iterable 19 : 

MyType[] myArray; // array is initialized with data somewhere 

for(MyType x: myArray) { 

// code involving x, i.e. each element in the array 
} 

It is important to remember that this syntax is used when one wants to process every element in an array (or 
an Iterable object) independent of order of processing because Java does not guarantee a traversal 
order. 

Let's look at an algorithm where we might not want to process the entire array: 

// Find the first index of a given value in an array 

int idx = -1; // initialize the index to an invalid value. 

for(int j=0; j <my Array . length ; j++) { //no initialization ; end index at length- 1; 

//increment index every time the loop is processed, 
if (desiredValue == myArray [j]) { // found match! 
idx = j; // save the index, 
break; // break out of the loop. 
} 
} 

Notes: 

• The only way you can tell if the desired value was actually found or not is if the value of idx is -1 or 
not. Thus the value of idx must be checked before it is ever used. 

• The resultant idx variable cannot be used as the index inside the loop because one would not be able 
to tell if the desired value was found or not unless one also checked the length of the array. This is 
because if the desired value was never found, idx at the end of the loop would equal the length of the 
array, which is only an invalid value if you already know the length of the array. 

• The break statement stops the loop right away and execution resumes at the point right after end of 
the loop. 

There is a counterpart to break called continue that causes the loop to immediately progress to the beginning 
of the next iteration. It is used much more rarely than break, usually in situations where there are convoluted 
and deeply nested if-else statements. 

Can you see that the price of the compact syntax of for loops is a clear understandability of the process? 



19 http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Iterable.html 
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4.4.2.1 While loops 

for loops are actually a specialized version of while loops, while loops have no special provisions for 
initialization or loop incrementing, just the termination condition. 

while loops iterate through the loop body until the termination condition evaluates to a false value. 

The following for loop: 

for ( [initialization statement]; [termination expr] ; [increment statement]) { 

[loop body] 

} 

Is exactly equivalent to the following: 

{ 

[initialization statement] ; 

while ( [termination expr]) { 

[loop body] 

[increment statement] ; 

} 

} 

Note the outermost curly braces that create the scoping boundary that encapsulates any variable declared 
inside the for loop. 

The Java compiler will automatically convert a for loop to the above while loop. 

Here is the above algorithm that finds a desired value in an array, translated from a for loop to a while 
loop: 

// Find the index of the first occurance of desiredValue in my Array, using a while loop. 

{ 

idx = -1; // initialize the final result 

int j =0; // initialize the index 

while (j < myArray . length) { // loop through the array 

if (desiredValue == myArray [j]) { // check if found the value 

idx = j ; // save the index 

break; // exit the loop. 

} 

j++; // increment the index 

> 
> 

Basically, for loops give up some of the flexibility of a while loop in favor of a more compact syntax. 
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while loops are very useful when the data is not sequentially accessible via some sort of index. Another 
useful scenario for while loops is when the algorithm is waiting for something to happen or for a value to 
come into the system from an outside (relatively) source. 

do-while loops are the same as while loops except that the conditional statement is evaluated at the 
end of the loop body, not its beginning as in a for or while loop. 

See the Java Resources web site page on loops 20 for more information on processing lists using while 
loops. 

4.4.2.2 for-each loops 

An exceedingly common f or-loop to write is the following; 

Stuff [] s_array = new Stuff [n] ; 
// fill s_array with values 

for(int i = 0; i < s_array. length; i++) { 

// do something with s_array[i] 

} 

Essentially, the loop does some invariant processing on every element of the array. 

To make life easier, Java implements the for-each loop, which is just an alternate for loop syntax: 

Stuff [] s_array = new Stuff [n] ; 
// fill s_array with values 

for (Stuff s:s_array) { 
// do something with s 
} 

Simpler, eh? 

It turns out that the for-each loop is not simply relegated to array. Any class that implements the 
Iterable interface will work. This is discussed in another module, as it involves the use of generics. 

4.4.3 Arrays vs. Lists 

In no particular order... 

• Arrays: 

Fast access to all elements. 

Fixed number of elements held. 

Difficult to insert elements. 

Can run into problems with uninitialized elements. 

Minimal safety for out-of-bounds indices. 

Minimal memory used 

Simple syntax 

Must use procedural techniques for processing. 

Often incompatible with 00 architectures. 

Difficult to prove that processing algorithms are correct. 

Processing algorithms can be very fast. 

Processing algorithms can be minimally memory intensive 



D http://www. exciton.cs.rice.edu/JavaResources/ Java/loops. htm 
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• Lists: 



Slow access except to first element, which is fast. 

Unlimited number of elements held. 

Easy to insert elements. 

Encountering uninitialized elements very rare to impossible. 

Impossible to make out-of-bounds errors. 

Not optimized for memory usage. 

More cumbersome syntax. 

Can use 00 and polymorphic recursive techniques for processing. 

Very compatible with 00 architectures. 

Easy to prove that processing algorithms are correct. 

Processing algorithms can be quite fast if tail-recursive and using a tail-call optimizing compiler. 

Processing algorithms can be very memory intensive unless tail-recursive and using a tail-call 

optimizing compiler. 



NOTE: Arrays are optimized for size and random access speed at the expense of 00 design and 
recursion. If you do not need speed or low memory, do not use an array. If you must use an array, 
tightly encapsulate it so that it does not affect the rest of your system. 



Chapter 5 

Restricted Access Containers 

5.1 Restricted Access Containers 1 

5.1.1 Introduction 

Stacks and queues are examples of containers with special insertion and removal behaviors and a special 
access behavior. 

Insertion and removal in a stack must be carried out in such a way that the last data inserted is the first 
one to be removed. One can only retrieve and remove a data element from a stack by way of special access 
point called the "top". Traditionally, the insertion and removal methods for a stack are called push and 
pop, respectively, push inserts a data element at the top of the stack, pop removes and returns the data 
element at the top of the stack. A stack is used to model systems that exhibit LIFO (Last In First Out) 
insert /removal behavior. 

Data insertion and removal in a queue must be carried out in such a way that the first one to be 
inserted is the first one to be removed. One can only retrieve and remove a data element from a queue 
by way of special access point called the "front". Traditionally, the insertion and removal methods for a 
queue are called enqueue and dequeue, respectively, enqueue inserts a data element at the "end" of the 
queue, dequeue removes and returns the data element at the front of the queue. A queue is used to model 
systems that exhibit FIFO (First In First Out) insertion/removal behavior. For example, one can model 
a movie ticket line by a queue. 

We abstract the behaviors of special containers such as stacks and queues into an interface called 
IRAContainer specified as follows. 

5.1.2 Restricted Access Containers 
5.1.2.1 IRAContainer .Java 

package rac; 

import listFW.*; 
/** 
* Defines the interface for a restricted access container. 
*/ 
public interface IRAContainer { 
/** 
* Empty the container. 



lr rhis content is available online at <http://cnx.org/content/ml7101/!. l/>. 
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* NOTE: This implies a state change. 

* This behavior can be achieved by repeatedly removing elements from this IRAContainer . 

* It is specified here as a convenience to the client. 
*/ 

public void clear(); 
/** 

* Return TRUE if the container is empty; otherwise, return 

* FALSE. 
*/ 

public boolean isEmptyO; 
/** 

* Return TRUE if the container is full; otherwise, return 

* FALSE. 
*/ 

public boolean isFullO; 
/** 

* Return an immutable list of all elements in the container. 

* @param fact for manufacturing an IList. 
*/ 

public IList elements (IListFactory fact); 
/** 

* Remove the next item from the container and return it . 

* NOTE: This implies a state change. 

* @throw an Exception if this IRAContainer is empty. 
*/ 

public Object get(); 
/** 

* Add an item to the container. 

* NOTE: This implies a state change. 

* @param input the Object to be added to this IRAContainer. 

* @throw an Exception if this IRAContainer is full. 
*/ 

public void put (Object input); 
/** 

* Return the next element in this IRAContainer withour removing it . 

* @throw an Exception if this IRAContainer is empty. 
*/ 

public Object peekQ ; 



1. Restrict the users from seeing inside or working on the inside of the container. 

2. Have simple put (data) and getQ methods. Note the lack of specification of how the data goes in or 
comes out of the container. 

3. However, a "policy" must exist that governs how data is added ("put") or removed ("get"). Examples: 

• First in/First out (FIFO) ("Queue") 

• Last in/First out (LIFO) ("Stack") 

• Retrieve by ranking ("Priority Queue") 

• Random retrieval 

4. The policy is variant behavior -> abstract it. 
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• The behavior of the RAC is independent of exactly what the policy does. 

• The RAC delegates the actual adding ("put") work to the policy. 

• The RAC is only dependent on the existence of the policy, not what it does. 

• The policy is a "strategy" for adding data to the RAC. See the Strategy design pattern 2 . 

• Strategy pattern vs. State pattern 3 - so alike, yet so different! 

The manufacturing of specific restricted access containers with specific insertion strategy will be done by 
concrete implementations of the following abstract factory interface. 

5.1.2.2 IRACFactory.java 

package rac; 

/** 
* Abstract Factory to manufacture RACs. 
*/ 
public interface IRACFactory { 
/** 
* Returns an empty IRAContainer . 
*/ 
public IRAContainer makeRACO; 
} 



5.1.3 Examples 

The following is an (abstract) implementation of IRACFactory using LRStruct as the underlining data 
structure. By varying the insertion strategy, which is an IAlgo on the internal LRStruct, we obtain different 
types of RAC: stack, queue, random, etc. 



2 http://cnx.org/content/ml7037/latest/ 
3 http://cnx.org/content/ml7047/latest/ 
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Figure 5.1: UML diagram of the abstract RAC and RAC factory definitions plus a few concrete RAC 
factories. 



The source code for the following examples can be downloaded at this link 4 
5.1.3.1 ALRSRACFactory.java 



package rac; 

import listFW.*; 

import listFW.f actory .*; 

import Irs . * ; 

/** 

* Implements a factory for restricted access containers. These 

* restricted access containers are implemented using an LRStruct to 

* hold the data objects. 
*/ 

public abstract class ALRSRACFactory implements IRACFactory { 
/** 

* Implements a general-purpose restricted access container using 

* an LRStruct. How? 
* 

* The next item to remove is always at the front of the list of 

* contained objects. This is invariant! 
* 

* Insertion is, however, delegated to a strategy routine; and 



4 http://cnx.org/content/ml7101/latest/rac. zip 
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* this strategy is provided to the container. This strategy 

* varies to implement the desired kind of container, e.g., queue 

* vs. stack. 
* 

* This nested static class is protected so that classes derived from its 

* factory can reuse it to create other kinds of restricted access 

* container. 
*/ 

protected static class LRSRAContainer implements IRAContainer { 
private IAlgo _insertStrategy ; 
private LRStruct _lrs; 

public LRSRAContainer (IAlgo strategy) { 

_insertStrategy = strategy; 

_lrs = new LRStruct (); 
} 

/** 

* Empty the container. 
*/ 

public void clear () { 

_lrs = new LRStruct (); 

> 

/** 

* Return TRUE if the container is empty; otherwise, return 

* FALSE. 
*/ 

public boolean isEmptyO { 

return (Boolean) _lrs . execute (CheckEmpty . Singleton) ; 
} 

/** 

* Return TRUE if the container is full; otherwise, return 

* FALSE. 
* 

* This implementation can hold an arbitrary number of 

* objects. Thus, always return false. 

*/ 

public boolean isFullO { 

return false; 
} 

/** 

* Return an immutable list of all elements in the container. 
*/ 

public IList elements (final IListFactory fact) { 
return (IList) _lrs. execute (new IAlgo () { 

public Object emptyCase (LRStruct host, Object... nu) { 
return fact .makeEmptyList () ; 

> 
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public Object nonEmptyCase(LRStruct host, Object... nu) { 
return f act .makeNEList (host .getFirst() , 

(IList)host .getRest () .execute (this)) ; 
} 

»; 

} 

/** 

* Remove the next item from the container and return it . 
*/ 

public Object get() { 

return _lr s . removeFront ( ) ; 

> 

/** 

* Add an item to the container. 

*/ 

public void put (Object input) { 

_lrs. execute (_insertStrategy, input) ; 
} 

public Object peek() { 

return _lr s . getFir st ( ) ; 
} 
} 
} 

/** 
* Package private class used by ALRSRACFactory to check for emptiness of its internal LRStruct . 
*/ 
class CheckEmpty implements IAlgo { 

public static final CheckEmpty Singleton= new CheckEmpty () ; 

private CheckEmpty () { 

} 

public Object emptyCase (LRStruct host, Object... input) { 

return Boolean. TRUE; 
} 

public Object nonEmptyCase (LRStruct host, Object... input) { 

return Boolean. FALSE; 
} 



5.1.3.2 LRSStackFactory.java 

package rac; 
import Irs . * ; 
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public class LRSStackFactory extends ALRSRACFactory { 
/** 
* Create a ''last-in, first-out'' (LIFO) container. 
*/ 
public IRAContainer makeRACO { 

return new LRSRAContainer(new IAlgoO { 

public Object emptyCase(LRStruct host, Object... input) { 

return host . insertFront (input [0] ) ; 
} 

public Object nonEmptyCase(LRStruct host, Object... input) { 

return host . insertFront (input [0] ) ; 
} 

»; 
} 



5.1.3.3 LRSQueueFactory.java 

package rac; 

import Irs . * ; 

public class LRSQueueFactory extends ALRSRACFactory { 
/** 
* Create a ''first-in, first-out'' (FIFO) container. 
*/ 
public IRAContainer makeRACO { 

return new LRSRAContainer(new IAlgoO { 

public Object emptyCase(LRStruct host, Object... input) { 

return host . insertFront (input [0] ) ; 
} 

public Object nonEmptyCase(LRStruct host, Object... input) { 

return host .getRestO .execute (this, input); 
} 

»; 



5.1.3.4 RandomRACFactory.java 

package rac; 
import Irs . * ; 

/* 
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* Implements a factory for restricted access containers, including a 

* container that returns a random item. 
*/ 

public class RandomRACFactory extends ALRSRACFactory { 
/** 
* Create a container that returns a random item. 

*/ 

public IRAContainer makeRACO { 

return new LRSRAContainer(new IAlgoO { 

public Object emptyCase(LRStruct host, Object... input) { 

return host . insertFront (input [0] ) ; 
} 

public Object nonEmptyCase(LRStruct host, Object input) { 
/* 
* Math . Random returns a value between . and 1.0. 
*/ 
if (0.5 > Math.randomO) 

return host . insertFront (input [0] ) ; 
else 

return host .getRest() .execute (this, input); 
} 

»; 

} 
} 

But can we push the abstraction further? Is the difference between a stack and a queue really anything 
more than how the data is ordered? 

Now, let's go on an look at the ordering object and priority queues... 5 

5.2 Ordering Object and Priority Queue 6 

Placeholder. Content to be added later. 



5 http://cnx.org/content/ml7064/latest/ 

6 This content is available online at <http://cnx.org/content/ml7064/!. l/>. 



Chapter 6 

GUI Programming 

6.1 Graphical User Interfaces in Java 1 

6.1.1 Graphical User Interfaces in Java 

In Java Graphical User Interface (GUI) programming, we do not build GUI components from scratch. 
Instead we use GUI components provided to us by the JDK. Java has two types of GUI applications: stand- 
alone GUI applications and applets. We first study how to build stand-alone GUI applications (GUI app 
for short). 

Every GUI app uses what is called a JFrame that comes with the JDK. A JFrame is a window with 
borders, a title bar, and buttons for closing and maximizing or minimizing itself. It also knows how to resize 
itself. Every GUI app subclasses JFrame in some way to add more functionality to the window frame. One 
common task is to tell the system to terminate all "threads" of the GUI app when the user clicks on the exit 
(close) button of the main GUI window. We encapsulate this task in an abstract frame class called AFrame 
described below. 

6.1.2 0. Abstract Frame (AFrame.java) 

NOTE: The source code for AFrame is available in the glossary. 



6.1.2.1 Event 

When the user interacts with a GUI component such as clicking on it or holding the mouse down on it and 
drag the mouse around, the Java Virtual Machine (JVM) fires appropriate "events" and delivers them to 
the GUI component. It is up to the GUI component to respond to an event. The abstract notion of events is 
encapsulated in an abstract class called AWTEvent provided by Java. Specific concrete events are represented 
by appropriate concrete subclasses of AWTEvent. 

For example, when the user clicks on the close button of a JFrame, the JVM fires a window event 
represented by the class WindowEvent and delivers it to the JFrame. By default, the JFrame simply hides 
itself from the screen while everything else that was created and running before the JFrame disappears from 
the screen is still alive and running! There is no way the user can redisplay the frame again. In the case 
when the JFrame is the main window of a GUI app, we should terminate everything when this main frame is 
closed. The best way to ensure this action is to "register" a special window event "listener" with the JFrame 
that will call the System class to terminate all threads related to the current program and exit the program. 
The code looks something like this: 



■'^This content is available online at <http://cnx.org/content/ml7185/!. 3/>. 
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addWindowListener (new WindowAdapterO { 

public void windowClosing(WindowEvent e) { 

System. exit (0) ; 
} 

»; 

Every time we write the constructor for a main frame of a GUI app, we invariably find ourselves writing 
the above lines of code to exit the program plus some additional application specific code to initialize the 
frame. So, instead of M copy-and-paste M the above code ("opportunistic" re-use), we capture this invari- 
ant task in the constructor of an abstract class called AFrame and reuse the code by subclassing from it. 
The application specific code to initialize the main frame is relegated to the specific concrete subclass of 
AFrame and is represented by an abstract method called initialize () . The constructor for AFrame calls 
initialize () , which, at run-time, is the concrete initialization code of the concrete subclass of AFrame that 
is being instantiated, as shown below. 

public AFrame (String title) { 

// Always call the superclass's constructor: 
super (title) ; 

addWindowListener (new Java. awt .event .WindowAdapterO { 

public void windowClo sing (Java. awt .event .WindowEvent e) { 

System. exit (0) ; 
} 

»; 

initializeQ ; 



NOTE: See the full code listing for more information 

6.1.2.2 Template Method Pattern: Expressing Invariant Behavior in terms of Variant Behaviors 

NOTE: The code for the classes AFrame, Frame A, Frame AB, and Frame AC are available in 
the glossary. 

The code for AFrame is an example of what is called the Template Method Pattern 2 . This design pattern 
is used to expresses an invariant and concrete behavior that consists of calls to one or more abstract 
methods. An abstract method represents a variant behavior. In other words, the template design pattern 
is a means to express an invariant behavior in terms of variant behaviors. We shall see this pattern used 
again in expressing sorting algorithms. 

6.1.2.2.1 Caveat 

As stated earlier, the call to initialize () in the constructor of AFrame will only invoke the concrete 
initialize () method of the concrete descendant class of AFrame that is being instantiated. Because 
initialize () is polymorphic, care must taken to ensure proper initialization of descendant classes that are 



"Template Design Pattern" <http://cnx.org/content/ml7188/latest/> 
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more than one level deep in the inheritance hierarchy of AFrame. Consider the following inheritance tree as 
illustrated by the following UML class diagram. Click here to see the code. 
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K 



Figure 6.1 



In overriding the initialize () method of FrameA, a direct subclass of AFrame, we should not 
invoke the initialize () method of the superclass AFrame via the call super . initialize () because 
super . initialize () is abstract. However, the initializeO method of any subclass of FrameA and below 
should make a call to the initializeQ method of its direct superclass in order to ensure proper initialization. 
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For example, in the above diagram, new FrameAB( M ab M ) calls the constructor Frame AB, which calls the 
constructor FrameA, which calls the constructor AFrame, which calls 

• the constructor JFrame and then calls 

• initialize () , which is the initializeO method of FrameAB which calls 

• super . initializeO , which should properly initialize FrameA, and then calls 

• the additional initialization code for FrameAB. 

Exercise 6.1 

What is the chain of calls when we instantiate a FrameAC 



6.1.3 1. Simple JFrame (FrameO.java) 

NOTE: FrameOApp.java is available in the source code archive file 3 . 

FrameOApp. Java represents one of the simplest GUI application in Java: it simply pops open an FrameO 
object. FrameO is subclass of AFrame that does nothing in its concrete initializeO method. 

6.1.4 2. JFrame with JButtons but no event handlers (Framel.java) 

NOTE: Framel.java is available in the source code archive file 4 . 

To display other GUI components on a JFrame, we first need to get the content pane of the JFrame and then 
add the desired GUI components to this content pane. 

If we want to arrange the added GUI components in certain ways, we need to add an appropriate " layout 
manager" to the JFrame. The task of laying out the GUI component inside of a container GUI component 
is specified by an interface called LayoutManager. In Framel, we add the FlowLayout that arranges all 
GUI components in a linear fashion. If we do not add any layout manager to the JFrame, it has no layout 
manager and does a very bad job of arranging GUI components inside of it. As an exercise, comment out 
the code to add the FlowLayout to Framel and see what happens! 

6.1.4.1 Strategy Pattern 

JFrame is not responsible for arranging the GUI components that it contains. Instead it delegates such 
a task to its layout manager, LayoutManager. There are many concrete layout managers: FlowLayout, 
BorderLayout, GridLayout, etc. that arrange the internal components differently. There are said to be 
different strategies for layout. The interaction between JFrame and its layout manager is said to follow the 
Strategy Pattern 5 . 

The strategy pattern is powerful and important design pattern. It is based on that principle of delegation 
that we have been applying to model many of the problems so far. It is a mean to delineate the invariant 
behavior of the context (e.g. JFrame) and the variant behaviors of a union of algorithms to perform certain 
common abstract task (e.g. LayoutManager). We shall see more applications of the strategy design pattern 
in future lessons. 

At this point the only the buttons in the Framel example do not perform any task besides "blinking" 
when they are clicked upon. The example in the next lecture will show how to associate an action to the 
click event. 

Click here to download code samples. 6 



3 http://cnx.org/content/ml7185/latest/GUIl.zip 

4 http://cnx.org/content/ml7185/latest/GUIl.zip 

5 "Strategy Design Pattern" <http://cnx.org/content/ml7037/latest/> 

6 http://cnx.org/content/ml7185/latest/GUIl.zip 
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6.2 More Java GUI Programming 7 

6.2.1 1. JFrame with JButtons and event handlers (Frame2.java) 

NOTE: Click here to view Frame 2. Java, or download the entire archive 8 



6.2.1.1 Command Design Pattern 

When a user clicks on a button, an ActionEvent object is delivered to the button. In order for the button to 
perform an application specific task, we must register an ActionEventListener to the button and program 
this event listener to perform the task we want. The ActionListener class is an example of what is called a 
"command" from the Command Design Pattern 9 . The code to add an ActionListener to a button looks 
like: 

myButton.addActionListener(new ActionListener () { 
public void act ionPerf ormed( ActionEvent e) { 
// code to perform a task goes here... 

»; 

The example Frame2 shows how to dynamically change the layout manager for a JFrame by calling its 
setLayout ( . . . ) method resulting in a dynamic re-arrangement of the GUI components in the JFrame. 

6.2.2 2. JFrame with JButtons and Adapters (Frame3.java) 

NOTE: Click here to view Frame3.java, or download the entire archive 10 

Frame3 illustrates how to decouple the view from the rest of the world by having the view communicate 
to an interface called "adapter". A controller object, Frame3Controller connects the view Frame3 to the 
world by installing a concrete adapter into the view. The adapter is instantiated as anonymous inner object 
and has access to all of its outer object. The view does not and should not know anything about the world 
to which it is connected. This adds flexibility to the design. 



7 This content is available online at <http://cnx.Org/content/ml7186/l. 2/>. 
8 http://cnx.org/content/ml7186/latest/GUi2.zip 

9 http://www. exciton.cs.rice.edu/JavaResources/DesignPatterns/command. htm 
10 http://cnx.org/content/ml7186/latest/GUI2.zip 
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Figure 6.2 



6.2.2.1 Null-Object Pattern 

In much of the current programming practice, the special value null is often used as a flag to represent a 
gamut of different and often disconnected concepts such as emptiness and falseness. This can result in a lot 
of confusion and complex control structures in the code. In our view, null should only be used to denote the 
non-existence of an object, null is not an object and has no "intelligence" (i.e. behavior) for other objects 
to interact with. Therefore, whenever we work with a union of objects and discover that one or more of 
these objects may be referencing a null value, we almost always have to write code to distinguish null as 
a special case. To avoid this problem, we should think of adding a special object, called the null object, 
to the union with appropriate behavior that will allow us to treat all object references in a consistent and 
uniform way, devoid of special case consideration. This design pattern is called the null object pattern. We 
have used the null object pattern in one occasion: the EmptyNode to represent the empty state of a (mutable) 
list (LRStruct). 
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In Frame3 the view adapter, _v2wAdapter, is initialized to an (anonymous) IView2World object. It 
is there to guarantee that _v2wAdapter is always referencing a concrete IView2World object, and , since 
setV2WAdapter( . . .) only allows a non-null assignment, we can always call on _v2WAdapter to perform 
any method without checking for null. 
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Chapter 7 

Labs 

7.1 DrJava 1 

DrJava is a lightweight pedagogical environment for Java development created by Rice University. DrJava 
provides a way to edit and save Java code with key words highlighting, curly brace matching, and an 
interactive environment to manipulate objects and test code without having to write the main method. It 
can be freely downloaded from the WEB. Please see the DrJava home page 2 

7.1.1 Editing 

Definitions Pane: When you run DrJava you will see a window appear. This window (GUI) consists 
of four subwindows. The top half of the GUI constitutes the Definitions pane. You type in all the class 
definitions here. After you type in some code, you need to click on the save button before you can compile 
your code. All the classes in the Definitions pane will be saved in a single file. There should only be one 
public class in the Definitions window, and the saved file should have the same name as that of the public 
class with the extension Java. 

7.1.2 Compiling 

Compiler Output Pane: You compile your Java code by clicking on the Compile All button in the 
menu bar at the top. Every time you compile your code, DrJava will display all compile error messages 
here. Clicking on an error message will highlight the line where the error is suspected to take place in the 
Definitions pane. If there is no compile error, DrJava will declare success in this pane. 

7.1.3 Running 

Interactions pane: There are several ways to run your Java code. For now, we will restrict ourselves 
to the Interaction pane at the bottom of the main GUI window. This is where you can type in any valid 
Java statement. Usually, you would type in code to instantiate objects of classes defined in the Definitions 
window, and call their methods to check whether or not they perform correctly. Typing a valid Java 
expression terminated with a semi-colon and then pressing the Return (Enter) key, will cause DrJava to 
evaluate the expression but NOT printing the result. If you want DrJava to print the value of the result 
in the Interactions window, you should press Return without terminating the expression with a semi-colon. 
There is a menu item to reset (i.e. clear) the Interactions window. Another way to clear the Interactions 
window is to force a re-compile by editing the Definitions pane. If your code has printing statements, the 
output will be displayed in the Console Output pane. 



lr rhis content is available online at <http://cnx.Org/content/mll659/l. 5/>. 
2 http://www. drjava.org 
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7.1 A Testing 

There are many ways to test your code. The most formal way is to use JUnit testing facilities, which is 
covered in a separate module: Unit Testing with JUnit in DrJava (Section 7.2). For simple tests, you can 
test your code by directly interacting with it in the Interactions pane. 

7.1.5 Debugging 

To debug a program in DrJava, first put DrJava into Debugging Mode by setting the check box under 
the Debugger on the main menu. This will enable all the other debugging features. When debugging mode 
is active, the debugging pane will appear near the bottom of the DrJava window. This pane contains the 
Watch window and tabs that show the current Stack and Threads status. The debugging pane also has 
buttons for Resume debugging, Step Into, Step Over and Step Out. These features are described in 
detail below. 

The basic technique for debugging is to set breakpoints on lines of code that are of interest/problematic 
and then to either step slowly through the code execution from that point and/or to examine the values of 
various variables. 

Breakpoints: Under debugging mode, DrJava will stop the execution of a program whenever a break- 
point is encountered. Execution stops before the breakpoints line of code is run. To set or clear a breakpoint, 
place the cursor on the desired line of code and either use the Debugger/Toggle Breakpoint on Current 
Line or by simply pressing Ctrl-B or by right-clicking the desired line and selecting Toggle Breakpoint. 
Note that it only makes sense to put a breakpoint on a line of code that actually executes, which excludes 

• Blank lines 

• Comments 

• Method signature lines 

• Lines with a single curly brace on them. 

• Field/attribute declarations that have no initialization code. 

To clear a breakpoint, follow the same procedure used to set the breakpoint. 

Whenever the program execution is stopped on a line of code, the Interactions pane can be used to 
examine the value of any variable that is in scope or even to execute methods on those variables (if they are 
objects). You can even set the values of any available variables by assigning a new value to them. This is 
useful if they have the wrong value for some reason and you want to check if the rest of your code will run 
properly if the correct value is present. 

Clear All Breakpoints: Clicking on Debugger/Clear All Breakpoints will clear all breakpoints 
that have been set in your program. 

Clicking on Debugger/Breakpoints or pressing Ctrl+Shift+B will bring up a tabbed pane at the 
bottom of the DrJava window that enables you to conveniently examine, navigate to, delete, or disble 
(without deleting) all of the breakpoints in your program. 

Step Into: When execution has stopped on a line of code, clicking on the Step Into button in the 
debugging pane or selecting the menu item Debugger/Step Into or pressing F12 will cause the current 
line of code (highlighted in blue) to be executed. If the current line of code involves the invocation of a 
method, then the current line of code will be advanced into the first method to be called, as per Java's order 
of execution rules. If the current line of code is the last line in a method, the current line of code will become 
the next executable line of code in the method that called the current method. Note that if the caller's line 
of code involved multiple method calls, then the current line of code will return to that line of code in the 
caller and then execution will advance into the next method to be called, or if the current method was the 
last method to be called, the current line of code will be the next line of code in the caller. 

Step Over: When execution has stopped on a line of code, clicking on the Step Over button in the 
debugging pane or selecting the menu item Debugger/Step Over or pressing Fll will cause the current 
line of code to be executed. This is very similar to Step Into, but if the the execution will not stop inside 
of any methods called in the current line of code. Thus the new current line of code will always be in the 
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same method, unless the executed line was the last line in the method, upon which execution will stop in the 
calling method as usual. This feature is very useful when you are confident that the methods being called 
work properly and you are not interested in their detailed execution. 

Step Out: When execution has stopped on a line of code, clicking on the Step Out button in the 
debugging pane or selecting the menu item Debugger/ Step Out or pressing Shift +F 12 will cause the 
execution to resume until the current method exits. Excution will stop at the next executable line in the 
calling method. This is very useful to quickly exit a method whose detailed execution no longer interests 
you (for instance, if you accidentally stepped into a method that you wanted to step over). 

Resume Debugging: When execution has stopped on a line of code, clicking on the Resume button in 
the debugging pane or selecting the menu item Debugger/Resume Debugging or pressing F7 will cause 
the program execution to resume and continue until the next breakpoint is encountered. This is useful when 
you are no longer interested in the detailed execution of the code until the next breakpoint. 

Watches: Watches are used when you want to continuously monitor the value of a particular variable. 
Simply type the name of the variable or field into the Watch pane and when code execution has paused, if 
that variable name is in scope, its value will be displayed. 

Stack: The stack contains an ordered list of all methods with pending operations at any given point of a 
program's execution. That is, when the program execution has stopped at a particular line of code, the stack 
contains the method that line of code is in, the method that called that method, the method that called 
that method, etc. In DrJava, the Stack tab will show the stack with the current method at the top and 
the calling method below it. Looking at the stack is very useful for determining where in your program you 
actually are, as often a method is called from locations that are unintended or one discovers that a method 
is not being called from where you wish it to be called. 

Threads: A Java program run on many simultaneous execution paths or "threads", each performing 
different tasks necessary for the total operation of a Java application. A simple program written by a 
programmer may have a single thread that runs the code written by that programmer, but may also have 
many other threads performing such tasks as managing the graphical user interface ("GUI") or managing 
the memory allocated to the program. It is also possible for a programmer to write code that utilizes multiple 
threads of execution to accomplish the desired goals. The Threads tab is most useful for debugging these 
multi-threaded programs by enabling the developer to better understand which threads are accessing which 
objects. 

7.2 Unit Testing with JUnit in DrJava 3 

Object oriented systems derive great complexity through the interactions between the objects in the system. 
It is often impossible to test the entire range of the total complex behavior that a system is designed to 
exhibit. What one can say however is that if any given part of the system does not perform as desired, then 
one can make no assurances whatsoever about the integrity of the system as a whole. Thus the testing of 
these smaller parts, or "units" is a crucial element of developing any large-scale 00 system. A unit test is 
a complete test of a small, atomic sub-system. Note that this is not the same from a partial test of some 
aspect of the whole system! 

Unit tests are often performed at the individual class level, meaning that a test class that runs all the 
complete battery of tests on the tested class, is written for each class to be tested. In some cases however, 
certain systems of classes are not divisible into isolated, atomic units and in such must be tested as a whole. 
The key is to test as small a piece of the system as possible and to test it as thoroughly as possible. 

7.2.1 Using JUnit in DrJava 

Suppose we have a class such as the following that we wish to test. Note that class is public and that the 
method we wish to test is also public. 



3 This content is available online at <http://cnx.org/content/mll707/!. 4/>. 
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Sample Code To Be Tested 
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Figure 7.1: Some example code to be tested. 



In DrJava, select M File/New JUnit Test Case...". Enter a name that is descriptive of the test(s) you 
wish to make. A recommendation is to use the class name being tested prepended with " Test_ M , such as 
"Test_MyClass". This enables all your test classes to be easily identified, DrJava will then automatically 
create a valid JUnit test class, such as below. (Note that DrJava does not initially name the new class file, 
but the default name suggested by DrJava when you attempt to save it will be correct.) 
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Autogenerated Unit Test Class 



^T&st.MyClass - DrJava 
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/** 

* A test method. 
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* many "test Something" methods in this class as you wish, and each 
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public void testXO { 
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Figure 7.2: Test class autogenerated by DrJava. 



Rename the auto-generated "testXO" method to something more descriptive of the particular test 
you'd like to perform. The new name must start with "test" and must return void and take no input 
parameters. You can create as many test methods as you wish to test your code. JUnit will automatically 
run all methods that begin with "test" as test methods. Typically, a single test method will test a single 
method on the class under test. There are situations however where a single method under test may require 
several test methods to properly test its full range of operation. In the code that follows, the testXO 
method has been renamed to "test_myMethodl() ". 



7.2.1.1 assertEquals(...) 

There are a number of ways in which one can test that the proper result is produced. The simplest method 
is to compare a single output value to an expected value. For instance, suppose you are testing a method 
that returns a result. One can compare the actual returned value to the value one expects for the given 
inputs. There are two methods supplied by the j unit, frame work. Test Case class, which is the superclass of the 
test class generated by DrJava. The first is void as sertEquals (String f ailResponse, Object actual, 
Object expected) . The actual input parameter is the actual result of the method under test. The expected 
parameter is the expected result. failResponse is a String that JUnit/DrJava will display if the actual value 
does not "equal" the expected value. The assertEquals(. . .) method is overridden such that actual and 
expected values can be either Objects or primitives. assertEquals( . . .) uses the equals (. . .) method 
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of Object to makes it determination. For primitives, the usual == is used. For instance, we could write the 
test case below. If the actual value does not equal the expected value, assertEquals throws a exception 
that is caught by the JUnit framework and an error message will result. To test the code, first compile all 
the code then select the test class. Right-click the test class and select "Test Current Document "or click 
on "Tools/Test Current Document." The following result will be displayed, given the test code we wrote to 
purposely fail: 

Using assert Equals (...) in a test case 
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* Test method for MyClass, tnyMethodl [) . 
V 
public void test_myHethodl () | 

MyClass mc = new KyClassO; 

String actual = mc. tnyMethodl (42) ; 

String expected = n Hy answer is "+42; 

£S sett Equals ( "KyClass.myMet hodl (42) *\ 



expected, actual) ; 



1 test failed: 
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Figure 7.3: assertEquals ( . . .) displays the error string as well as comparative information if the 
actual and expected values are not equal. 



As shown on the screen shot, DrJava clearly indicates in red the test method that failed and the difference 
between the expected and actual values. It also highlights the line of code in the test method where the 
failure occured. 

There is one exception to the syntax of assertEquals, and that is when the values being compared are 
doubles. This is because round-off errors in calculating floating point values means that it is almost always 
impossible to generate the same value from two different calculations, even if mathematically they are the 
same. For instance, compate 2.3*2.3 and 5.29. Mathematically identical, but on a PC running Windows, 
Java calculates them to be different by approximately 0.00000000000000089 (or 8.9e-16 in Java syntax). 
Thus, if the expected and actual values are to be of type double, then a 4'th input parameter is required. 
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This last parameter is a tolerance value, a plus-or-minus amount within which one considers the expected 
and actual values to be equal. For instance: 

assertEquals ("Testing doubles: 5.29 vs. 2.3*2.3", 5.29, 2.3*2.3, 9e-16) ; 
should pass, but 

assertEquals ("Testing doubles: 5.29 vs. 2.3*2.3", 5.29, 2.3*2.3, 8e-16) ; 
should fail. Note that the tolerance value should always be a positive value. 

7.2.1.2 assertTrue(...) 

Another method provided by TestCase is void assert True (String f ailResponse, boolean result). 
This is a simplified version of assertEquals ( . . .) used when the result can be expressed as a boolean 
true or false. Note that any test using assertTrue can also be written as assertEquals (f ailResponse, 
result, true). For instance we could write another test method to test the myMethod2 ( ) method of 
MyClass. The test class now has two test methods and JUnit will run both ot them when we click on "Test 
Current Document." Here, the second test method passes as shown in green below. The first method still 
fails and its error messages are still shown. Clicking on the error message will highlight the line where the 
error occured. Correcting the code in myMethodl (...) would result in all the test methods being listed in 
green with no error messages. 
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Using assert True (...) in a test method 
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public void test_HiyHathodl [) I 
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assertEquals ( "Hyclass. myMethodl H2) ", expected, actual); 
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*/ 
public void test_tnyHathod2 () ( 
M/Class nc = new MyCless J 
int actual « me . myMethodS ("99 "J i 
int expected = 42+99; 
assertTrue ( "My Class . myHethod2 f\ "99\ ") ", (actual == expected) ) ; 
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Figure 7.4: assertTrue( . . . ) is used in test_myMethod2( . . . ) above and does not generate an error 
because it is executed with a boolean true value. 



7.2.1.3 fail(...) 

For more complex testing, TestCase provides the void fail (String f ailResponse) method. Calling this 
method will immediately cause the test method to fail and the f ailResponse string will be displayed. Since 
this method does not know the actual or expected results, the f ailResponse string should contain more 
detailed information about what exactly failed and how it failed. In the next screen shot is an example of 
using f ail( . . . ) where the test code was written such that it would fail: 
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Using fail(...) in a test method 
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Figure 7.5: The fail(. . .) method immediately throws an error exception when it is executed. 



7.2.1.4 Additional Capabilities 

Note that any test method can call other methods if needed . This is useful when the testing procedure is 
complex and needs to be broken down into smaller pieces. Do not name these helper methods starting with 
"test" or they will be run separately as test cases! Using helper methods is also useful when certain types of 
tests are performed only under certain conditions. assertEquals( . . . ) , assert True ( . . . ) and f ail( . . . ) 
can be called from anywhere, but the DrJava will only highlight the line in the main test method that 
generated the error, i.e. the line that called the helper method. It will not highlight the line in the helper 
method where the actual call to assertEquals( . . . ) , assert True ( . . . ) or f ail( . . . ) was made. 

Sometimes in complex testing scenarios, there is a significant amount of initialization work required to 
set up the system to be tested. This is often the case when testing a system of interdependent objects where 
the entire system must be set up before any single object can be tested. If the initialization code is the 
same for all the tests being conducted, the method protected void setup () can be declared and be used 
to execute the necessary initializations. To insure "clean" test runs, JUnit/DrJava re-instantiates the test 
class before running each test method. The setup () method, if it exists, is called before any test method 
is executed. This means that the test class cannot utilize any internal field values that one test method 
modifies and another test method expects to use as modified. 

Likewise, in the event that after a test is run that significant amounts of common "clean-up" code is 
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required, one can declare the method protected void tearDown(). This method runs after each test method 
and is useful for insuring, for instance, that files and network connections are properly closed and thus keep 
them from interfering with other tests. 

The help system in DrJava has more detailed information on testing with JUnit, including how to create 
a test suite of multiple tests. 



Chapter 8 

Resources 

8.1 Java Syntax Primer 1 

This module contains an assortment of topics covering Java syntax. It is not intended to be a complete 
tutorial. 

8.1.1 Constructors 

A constructor can be thought of as a specialized method of a class that creates (instantiates) an instance of 
the class and performs any initialization tasks needed for that instantiation. The sytnax for a constructor is 
similar but not identical to a normal method and adheres to the following rules: 

• The name of the constructor must be exactly the same as the class it is in. 

• Constructors may be private, protected or public. 

• A constructor cannot have a return type (even void). This is what distinguishes a constructor from 
a method. A typical beginner's mistake is to give the constructor a return type and then spend hours 
trying to figure out why Java isn't calling the constructor when an object is instantiated. 

• Multiple constructors may exist, but they must have different signatures, i.e. different numbers and/or 
types of input parameters. 

• The existence of any programmer-defined constructor will eliminate the automatically generated, no 
parameter, default constructor. If part of your code requires a no parameter constructor and you 
wish to add a parameterized constructor, be sure to add another, no-parameter constructor. 

Example 8.1 

public Person { 

private String _name; 
public Person (String name) { 
_name = name; 



lr rhis content is available online at <http://cnx.org/content/mll791/!. l/>. 
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} 

The above code defines a public class called Person with a public constructor that initializes 
the _name field. 

To use a constructor to instantiate an instance of a class, we use the new keyword combined with an 
invocation of the constructor, which is simply its name and input parameters, new tells the Java runtime 
engine to create a new object based on the specified class and constructor. If the constructor takes input 
parameters, they are specified just as in any method. If the resultant object instance is to be referenced by 
a variable, then the type of the newly created object must be of the same type as the variable. (Note that 
the converse is not necessarily true!). Also, note that an object instance does not have to be assigned to a 
variable to be used. 

Example 8.2 

Person me = new Person ("Stephen") ; 

The above code instantiates a new Person object where _namefield has the value "Stephen". 



8.2 Connexions 

8.2.1 Viewing Connexions Content 2 

See the Introduction to Connexions 3 module for an overview of Connexions. 

8.2.1.1 Searching the Content Commons 

You can search the Content Commons for a specific module or a course using the Search button and 
text box in the upper right of the Connexions web pages. Type in a name, keyword, course title, module 
title, text string, or object ID in the Search text box and click Search. Connexions will display a list of all 
modules and courses that match your entry. To view a module or course, click its title. 

8.2.1.2 Opening a Collection or Course 

Select the "Content" tab (above the You are here Breadcrumb bar) to display the Content Commons 
(Figure 8.1) screen. This tab allows you to search for modules or courses by title, author name, or subject 
area. You can also display a listing of all content by subject, title, author name, keyword, popularity, and 
more by selecting the appropriate item under the "Browse All Content" heading on the tab. 



2 This content is available online at <http://cnx.Org/content/mll837/l.13/>. 
3 "Introduction to Connexions" <http://cnx.org/content/ml0884/latest/> 
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Figure 8.1: Connexions Courses 



8.2.1.3 Navigating Within a Collection or Course 

When you first open a course, the course title page displays. This page contains two panels. One panel 
displays the Start Course link and course information, such as the institution, instructor, contributing 
authors, and a brief description of the course. Click Start Course to display the entire course, beginning 
with the first module. The other panel is labeled "Course Contents" and it contains a table of contents for 
the course that lists the names of the sections and modules within that course. You can click a module name 
to display that module. 

Once you display a module from within a course, you can move to the previous module or to the next 
module in the course by clicking the <CPREV or NEXT^> links that appear in the upper right corner. 
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« PREVIOUS I NEXT » 



Figure 8.2: Links to the previous and next modules in a course 



NOTE: The <CPREV and NEXT^> links only display when you access a module from within a course. 
If you access a module directly from a browser, these links to do not appear. 



8.2.1.4 Viewing Related Material 

You can view content related to the module you are displaying using the links in the "Related Material" 
panel that appears to the left of the module content. This panel includes: 

• The names of other modules that contain content similar to the current module. Click a module name 
to display that module. 

• Any other courses that contain the current module. Click a course name to display that course. 



135 



RELATED MATERIAL 

Similar content 

■ Interval 

■ What is the confidence interval 
of an estimate? 

■ CONFIDENCE INTERVAL II 
More » 



Courses usiny this content 

■ Beginning Guitar 

■ Understanding Basic Music 
Theory 

■ Introduction to Music Theory 



Figure 8.3: Links to related material 



In the panel that appears to the right of the module content you can view links to examples, supplemental 
material, or prerequisite material provided by the module author. The importance of the links are shown by 
the number of bars in the box to the left of the link name. These links can be to material within Connexions 
or to a website outside of Connexions. 
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Figure 8.4: Links to pre-requisite materials, supplemental materials, and examples (not shown in this 
example) 



8.2.1.5 Displaying Information about the Module 

To display the metadata for the module, click the Metadata link at the end of the module. Metadata are 
non-content information about a module, such as the module ID, license type, version number, creation date, 
revision date, authors, maintainers, copyright holders, module name, keywords, and abstract. 

8.2.1.6 Viewing Module Revision History 

To view the revision history of a module, click the Version History link at the end of the module. When a 
new module is published Connexions assigns a revision number to that version of the module. If if becomes 
necessary to update the module, the author checks it out, edits it, and publishes it again. An incremented 
revision number is assigned to the updated version. Connexions stores all this revision information and you 
can view it on the History page for the module. 



8.2.1.7 Printing a Module 

To generate a PDF file of a module, which you can print, click the Print (PDF) link that appears in the 
upper left corner of the module in the "Content Actions" panel. Sometimes you may want or need a printed 
copy of the material for studying purposes. You can generate a PDF file for any module. These PDF files 
are formatted for printing with page numbers, headers, footers, and numbered headings. Since the printing 
process uses a PDF file, you must have a software package that can print PDF files installed on your PC. 
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Glossary 



A AFrame.java 



/** 

* Relegates to subclasses the responsibility 

* a well-defined state, 
package view; */ 



import j avax . swing .* ; // to use JFrame. \ 



protected abstract void initialize () ; 



/** 

rlT*T*rLV 

* Minimal reusable code to create a JFrame wrth a title and a window event 

* listener to call on System. exit () and f or cAttierim(Q^tbasdccfbrmi,eaiKaiiidom access 

* application that creates this JFrame. data structure where any element can be 

* ©author D . X . Nguyen accessed by specifying a single index 
*/ value corresponding to that element. 

public abstract class AFrame extends JFrame { Examp i e: a nArray[4] gives us itemE. 

Likewise, the statement anArray[7] = 
public AFrame (String title) { 42 ghould replace itemH wit h 42. 

// Always call the superclass's constuctor: 
super (title); assignment 

To set a variable to a particular data value. 
/** 

* Add an anonymous WindowAdapt© eB$nar£aH:<b#r to call System. exit to 

* force termination of the main appl i cat/ion, when n the Frame closes. n 

rr K (mutaolej binary Tree, HiTree, can be 

* Without it, the main application will still be running- even after, , 

rr in an empty state or^a non-empty state: 

* the frame is closed. 

* For illustration purpose, we use the fu^h^fic&af e em £}te ift r° ntams no 

* WindowAdpater and WindowEvent . data. 

* We could have imported java.awt .event .% W^^^o^c? 1 ^ JH^fei^ plains a 

* package names. ^ a ^ a object called the root element, 
*/ and 2 distinct BiTree objects called 

addWindowListener(new java.awt .event .Windo^«ciSpte^W e f and the ri S ht subtree - 

public void windowClo sing (java.awt .event .WindowEvent e) { 

System. out .print In (e) ; ^//MFM 8 illustration purpose only. 

System, exit (0) ; i. An abstract definition of a set of related 

y objects. A class definition specifies all the 

j ) > invariant behaviors and other attributes 

common to all the objects in the set. 
/** 

„ , ., n 2. In Java, the keyword .class denotes the 

* Subclasses are to do whatever is necessary to JLnliializje .the frame. 

u beginning of a class deimitipn. 



^ATTTnAm ^. -, ,_ b eginning ot a class dermiiipn . 

* CAVEAT: At run-time, when a concrete descendant class oi AFrame is 



* created, only the (concrete) T initiali.ze() method of this descendant 

-..-.-., JJ Definitions pane 

* class is called. ^ 



*/ The pane at the upper right of the DrJava 

initialize () ; window where one edits class definitions. 

} 
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F Frame2.java * Dynamically changes to a GridLayout with 5 

*/ 

protected void jblClicked(ActionEvent e) { 
package view; System. out . print In ("Set GridLayout..."); 

getContentPane () . setLayout (new GridLayout 
import java.awt.*; // to use Container. validate (); // forces this frame to re-1 
import j ava . awt . event .* ; // to use WindowAdpater a£d WindowEvent . 
import j avax . swing .* ; // to use JFrame. 

/** 

/** * Dynamically changes to FlowLayout . 

* A subclass of AFrame containing two JButtons tha£/have event handler called 

* "commands" to dynamically switch layout manager|f r j^e.t$4evfeB4"tj)BgCK§k€4^fe-§SonEvent e) { 

* upon. System. out. println("Set FlowLayout..."); 

* ©author D.X. Nguyen getContentPane (). setLayout (new FlowLayout 
*/ validateO; // forces this frame to re-1 

public class Frame2 extends AFrame { } 

} 
public Frame2 (String title) { 



} 



Frame2App.java 

super (title) ; *^ J 



protected void initialize () { P 8 PP> 

Container cp = getContentPane () ; 

■4-t w -en t +s\\ import j avax. swing.*; 

cp. setLayout (new FlowLayout (j j ; r . ° 

JButton jbl = new JButton("Grid Layout^ mi ; 0rt view '*' 

JButton jb2 = new JButton("Flow Layout"); 

cp.add(jbl); P ublic class Frame2 App i 

cp . add( jb2) ; 

t /\ . public static void main(String[] args) { 

JFrame f = new Frame2("A JFrame with 2 JE 

/ f . setVisible (true) ; 

-. D • .- v ji +-J .setSize(30Q,, 1QQ) ; .// Guess what this 

* Registers an anonymous event handler for the clicking of' button jpl. 

^ T „ .-uh • -. • i -, 4.x. • ,_ . ji f .setLoca-cion(.2Q0, 200); // Guess what t 

* When jbl is clicked upon, this event handler will respond by 

* executing its actionPerf ormed( . . . ) method. 

I II Forces the frame to re-layout its comp 

jbl .addActionListener(new ActionListener () { ' ' 

public void actionPerf ormed( Act ionEvenx e) { 

jblClicked(e); } 

} Frame 3. Java 

}); 

/** package view; 

* Same as the above. 

*/ import j ava . awt . * ; 

jb2.addActionListener(new ActionListenmj(drt[ j ava . awt . event .* ; 
public void actionPerf ormed( Act ionEnpantte^a^ax. swing. *; 

jb2Clicked(e) ; 
} /** 

}) ; * Same functionality as Frame2 but uses an adapt 

} * with the outside world instead. This design a 

* with the outside world. How the outside world 
/** * happen to the view is a variant behavior! 



GLOSSARY 139 

* Uses the Null-Object Pattern to initialize tfeje adapter avoiding checking for 

* null. public class Frame3App { 

* ©author DXN 

*/ public static void main (String [] args) { 

public class Frame3 extends Frame2 { new Frame3Controller () . constructFrameO .v 

} 

// Initializes the adapter to a null object: 

private IView2World _v2wAdapter = new JView2Wprld() A 

_, . _ „__,. , , /fl .Frarae3Coiitroirer.]ava 

public Object buttonlClicked (ActionEvent ej { 

return null; // does nothing! 
} 
public Object button2Clicked (ActionEvent B^ cl t a g e controller; 

return null; // does nothing! 
} import view.*; 

} . import j ava . awt . event . * ; 

import javax. swing. JFrame; 
public Frame3(String title) { import Java. awt.*; // For layout managers. 

super (title) ; 
y /** 

* The controller that instantiates a concrete IV 

public void setV2WAdapter(IView2World v2w) X tne world outside of Frame3 (the view) to Fran 

if (null == v2w) { * T ne concrete adapter is implemented as an anon 

throw new I HegalArgumentException( 5h Argument cannot be null!"); 
y public class Frame3Controller { 

_v2wAdapter = v2w; 
y public JFrame constructFrameO { 

// Local variable needs to be final so th 

/** // can access it: 

* Tells _v2wAdapter the button click event happenl^M 1 jftam e3 frame = new Frame3("View and 
*/ 

protected void jblClicked(ActionEvent e) { /** 

_v2wAdapter. buttonlClicked (e); * Install as concrete anonymous IView2Wc 

y * frame knowing what the adapter does. 

*/ 
/** frame. set V2WAdapter (new IView2World() { 

* Tells _v2wAdapter the button click event happens on jb2. 

*/ public Object buttonlClicked (ActionE 

protected void jb2Clicked(ActionEvent e) { frame. getContentPane (). setLayout( 

_v2wAdapter.button2Clicked(e) ; frame. validate () ; 

y return null; 

} 

} 

-n „ A . public Object button2Clicked (ActionE 

Frame3App.java r J 

frame . getContentPane ( ) . setLayout ( 

frame. validate () ; 
package app; return null; 

} 
import view.*; }) ; 

import controller.*; frame. setVisible (true) ; 

return frame; 
/** } 

* Instantiates the controller and builds the Irame! 
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Frame A .Java } 

/** 

* At run-time, when the constructor AFrame is 
package view; * executed, it calls this FrameAB initialize() 

* method and NOT the initialize () method of the 
/** * superclass FrameA. In order to reuse the 

* A direct concrete subclass of AFrame with its^ojgi^Jj^fgjogoflgdfor FrameA, we must make 

*/ * the super call to initialize () . 

public class FrameA extends AFrame { */ 

protected void initialize () { 

/** // Call initialize () of FrameA: 

* Calls AFrame constructor, which calls the cg^^ftf n j.^.j.^j.^^jzeO method 

* of this FrameA. This is done dynamically at run-time when a FrameA 

* object is instantiated. /** 

*/ * Additional application specific intializati 

public FrameA(String title) { * code for FrameAB goes here... 

super(title) ; */ 

> } 

} 

/** 

* The superclass initialize() method -Is abstract: don't call it here! 

. ,. . .F^ameALy.java , , . 

* Just write application specific initialization code for this FrameA here. 

*/ 
protected void initialize () { 

// Application specific intialization p@dfea^#rvF^LmeA goes here... 
} 
} /** 

* A second level descendant class of AFrame 
FrameAB. iava * that bypasses the initialize () method of 

* its direct superclass in its own 

* initialization code. Since proper 

* initialization of a subclass depends on 
package view; * proper initialization of the super class, 

* bypassing the initialization code of the 
/** * superclass is a BAD idea! 

* A second level descendant class of AFrame */ 

* that initializes itself by calling the 

* initialize () method of its direct super claspublic class FrameAC extends FrameA { 

* in addition to its own initialization code. 

*/ /** 

public class FrameAB extends FrameA { * Calls the superclass constructor, FrameA, 

* which in turns calls its superclass construct 
/** * AFrame, which first calls its superclass 

* Calls the superclass constructor, FrameA, * constructor, JFrame, and then executes the 

* which in turns calls its superclass constructornitializeO method of this FrameAC. 

* AFrame, which first calls its superclass */ 

* constructor, JFrame, and then executes the public FrameAC (String title) { 

* initializeO method of this FrameAB. super (title) ; 
*/ } 

public FrameAB (String title) { 

super(title) ; /** 
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* 
* 
* 
* 
* 
* 
* 
*/ 



At run-time, when the constructor AFrame is * Called by Frame3 when its button 2 is clic 

executed, it calls this initialize () method and*/ 

NOT the initializeO method of the superclass public Object button2Clicked (ActionEvent e) ; 

FrameA. This method does not call the supir 

class's initializeO method. As a result, the 

initialization done in the supercl^§s l4feral 

bypassed completely. This is a BAD idea! 



protected void initializeO { 

/** 



An explicit, concrete textual 
reprepresentation of a value of a given 
type. Literals are often used to set the 

A .. . ... . _,_ . .. . , values for variables. 

* Application specific mtialization code for 

* FrameAC goes here . . . 

*/ T type 

A set of values with certain common 
characteristics. In Java, all data values 
must be of some type. 



I Instantiate 

To create an object based on the 
specifications defined in a class definition. 
The object created is called an instance 
of that class. 

Interactions pane 

The pane at the lower edge of the Dr Java 
window where one can interactively 
execute Java statements. 

invariant 

The parts of a probram, such as values or 
programmatic behaviors, that do not 
vary from one invocation to the next. 
Note that while a value may be variant, 
an abstraction of that value may be 
invariant. 

I Vie w2 World .Java 



package view; 



import j ava . awt . event . * ; 



/** 



(e £ 'a' 'b' 'X' ' 
Adapter connecting Frame3 (the View) to the; out side World. 

followed by zero o 



*/ 
public interface IView2World { 
/** 
* Called by Frame3 when its button 1 is c 
*/ 
public Object buttonlClicked 



Example: int is a type that is used to 
represent integer number values, double 
is a type that is used to represent real 
number values. String is a type that is 
used to represent a string of characters. 

U UML 

Unified Modeling Language, developed by 
the Object Management Group ("OMG") 

Unit Test 

The testing of a single class or small 
collection of classes (a "unit") to verify 
correct behavior at a fine-grained level. 

V variable 

A memory location to hold a particular 
value of a given type. In a strongly-typed 
language such as Java, all variables must 
have a type. This is not true in all 
languages however. In a Java program, 
variables have names called indent ifiers, 
which are sequences of characters put 
together according to the following rule. 
A must begin with an alphabet character 
Y', etc.) and may be 
y zero or more alphabet 
characters and/or digit characters (e.g. 
'0', '1', etc.) and/or the underscore 
character ('_')• For examples, cp3PO is a 
valid variable name while Darth Vader is 
t because it has a blank character 
and the 'V. 



(ActionEvent e, , 

between the h 



/** 



variant 
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The parts of a program, such as values or 
programmatic behaviors, that vary from 



one invocation to the next. Note that 
while a value may be variant, its 
abstraction may be invariant. 
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Index of Keywords and Terms 

Keywords are listed by the section with that keyword (page numbers are in parentheses). Keywords 
do not necessarily appear in the text of the page. They are merely associated with that section. Ex. 
apples, § 1.1 (1) Terms are referenced by the page they appear on. Ex. apples, 1 



A abstract, § 2.3(27), § 3.4(55), 77 
Abstract Behavior, 79 
abstract classes, § 2.2(21) 
Abstract Construction, 79 
Abstract Environments, 79 
Abstract Factory Design Pattern, 63 
Abstract Factory Pattern, 57 
Abstract Structure, 79 
abstraction layers, § 1.1(1) 
access specifier, 5 
AFrame, 113, 114, 114, 115 
Algorithm, § 3.3(43) 
algorithms, § 4.3(93) 
annotation, § 8.2.1(132) 
anonymous, § 3.5(64) 
Applet, § 6.1(113) 
applets, 113 
array, 97, 97 

array processing, § 4.4(97) 
arrays, § 4.4(97) 

B Ballworld, § 2.2(21), § 2.3(27) 
behavioral abstraction, § 1.1(1) 
Binary Tree, 93 
binary trees, § 4.3(93) 
breakpoints, 122, 122 

C change, § 4.2(87) 
char, 2 

class, § 1.2(5) 
classes, 6, § 2.3(27) 
Clear All Breakpoints, 122 
closure, § 3.5(64), 76, 77 
code listing, 114 
command, § 6.2(117), 117 
command design pattern, § 6.2(117) 
component, § 3.4(55) 
composite, § 3.1(37) 
composite design pattern, 40 
composition, § 2.3(27) 
Composition ("has-a") lines, 12 
constructor, 5 



Content Commons, 132 

D data abstraction, § 1.1(1) 
Debugging Mode, 122 
decorator, 31 
decoree, 31 
Decoupling, § 3.3(43) 
delegates, 27 
dequeue, 105 

design, § 2.3(27), § 3.1(37), § 3.2(41), 
§ 3.3(43), § 3.4(55), § 4.1(85) 
design patterns, OOP, object oriented 
programming, polymorphism, inheritance, 
§ 2.1(15) 
double, 2 

dynamic, § 4.1(85) 
dynamic reclassification, § 4.2(87) 

E elements, 98 
encapsulated, 40 
enqueue, 105 
event listeners, 78 

F factory, § 3.4(55) 
fields, 5, 6 

FIFO (First In First Out), 105 
final, 77 

for each, § 4.4(97) 
for loop, § 4.4(97), 99 
for-each loop, 103 
Frame2, 117 
Frame2.java, 117 
Frame3, 117 
Frame3.java, 117 
Frame3Controller, 117 
FrameA, 114, 115 
Frame AB, 114, 116 
Frame AC, 114, 116 
framework, § 3.4(55), 89 

G graphical user interface, § 6.1(113), 113 
gui, § 6.1(113), 113, § 6.2(117), 123 



144 



INDEX 



gui programming, § 6.1(113) 

H helpers, § 3.5(64) 

hiding, § 3.4(55) 
hook, 91 

I Implementation ( M acts-like-a M ) lines, 11 
implements, 10 
indirection layer, 31 
information, § 3.4(55) 
inherit, 9 

inheritance, 16, § 2.2(21), § 2.3(27) 
Inheritance ("is-a") lines, 9 
Inheritance, composition, aggregation, 
abstraction, object oriented programming, 
object oriented design, OOP, OOD, § 1.3(9) 
inner, § 3.5(64) 
inner class, 77 
int, 2, 4 
interface, 10 
Interpreter, § 3.2(41) 
interpreter design pattern, 42 
invariant, 1, 114 
isomorphic, 38, 40 
IView2 World, 119 

J Java, § 1.2(5), § 4.3(93), § 4.4(97), § 5.2(112), 
§ 6.1(113), § 6.2(117) 
javagui, §6.1(113), §6.2(117) 
Java gui programming, § 6.2(117) 
Java, syntax, object oriented programming, 
§ 8.1(131) 
JFrame, § 6.1(113) 

K keyword, 6 

L lamdba, 78 

layout manager, 116 
levels of abstraction, 19 
LIFO (Last In First Out), 105 
linear recursive structure, § 4.2(87) 
list, § 3.1(37), § 3.2(41) 
locate, § 8.2.1(132) 

M members, 77 
metadata, 136 
method, 3 
methods, 6 
mutation, § 4.2(87) 

N nested, § 3.5(64) 
nested class, 77 
new, 3 



notes, § 8.2.1(132) 
null object, 118 
null-object pattern, 



6.2(117) 



O object, § 1.2(5), § 2.3(27), § 5.1(105) 
object oriented, § 5.2(112) 
object oriented design, § 2.2(21) 
object oriented programming, § 2.2(21) 
object-oriented, § 3.5(64) 
object-oriented programming, § 1.2(5) 
objects, 5 

on-the-fly, § 3.5(64) 
OO, § 3.5(64) 

OOD, § 2.2(21), § 2.3(27), § 5.2(112) 
OOP, § 1.2(5), § 2.2(21), § 2.3(27), § 3.1(37), 
§ 3.5(64), § 5.2(112) 
ordering, § 5.2(112) 
oriented, § 2.3(27) 
oriented programming, § 5.1(105) 
overriding, 24 

P package, 77 

Parnas, § 3.4(55) 

pattern, § 3.1(37), § 3.2(41), § 3.3(43), 

§ 3.4(55), § 4.1(85) 

polymorphism, 10, 16, § 2.2(21), § 2.3(27) 

priority, § 5.2(112) 

private, 63, 77 

private static, 60 

procedural abstraction, § 1.1(1) 

programming, § 2.3(27), § 5.2(112), § 6.2(117) 

protected, 77 

public, 5, 77 

Q queue, § 5.2(112) 

R RAC, § 5.1(105), § 5.2(112) 

reclassification, § 4.1(85) 

recursion, 40 

recursive, 38 

restricted access container, § 5.2(112) 

Resume Debugging, 123 

S separation of variant and invariant behaviors, 
25 

software component, 58 
spy objects, 79 
Stack, 122, 123 
state, § 4.1(85), § 4.2(87) 
state design pattern, § 4.2(87) 
static, 63 
static typing, 35 
Step Into, 122 
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Step Out, 123 
Step Over, 122 
strategy, § 6.1(113) 
strategy pattern, § 6.1(113) 
Structure, § 3.3(43) 
structures, § 4.3(93) 
student, § 8.2.1(132) 
subclass, 9 
superclass, 9 

template, § 6.1(113) 
template method, § 6.1(113) 
template method pattern, § 6.1(113) 
Threads, 122, 123 
tree, 93 
type, 1, 6 



U UML, class diagrams, object-oriented design, 
OOD, § 1.4(12) 
Union Design Pattern, 16 
unit test, 123 

unit testing, JUnit, DrJava, OOP, OOD, 
object oriented programming, object oriented 
design, § 7.2(123) 

V variant, 1 

view, § 8.2.1(132) 

Visitor, § 3.3(43) 

visitor design pattern, § 4.2(87) 

visitors, § 4.3(93) 

W Watch, 122 
Watches, 123 
while loop, § 4.4(97) 
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